This guide provides detailed information and instructions on:

How to configure WorkflowGen users and groups synchronization using Microsoft Entra ID

How to configure WorkflowGen authentication using OpenID Connect and Microsoft Entra ID

How to authorize access to mobile applications using OpenID Connect and Microsoft Entra ID

How to authorize WorkflowGen access to server-side scripts using OpenID Connect and Microsoft Entra ID

How to authorize WorkflowGen access to single-page applications using OpenID Connect and Microsoft Entra ID

How to configure Microsoft Entra ID for use with the WorkflowGen command line interface

How to configure WorkflowGen's Remote Approval service to integrate with Exchange Online using Modern authentication

How to configure the WorkflowGen database using Azure SQL database

How to configure the optional Read Scale-Out feature

How to configure Azure Load Balancer for higher availability and greater scalability

How to configure an Azure Files share to use in WorkflowGen

How to configure an Azure SendGrid SMTP with WorkflowGen

How to generate a universal link to simplify the WorkflowGen Plus v2 mobile app user login

How to set up and manage a Kubernetes cluster tailored for WorkflowGen in Azure

Overview

This section provides instructions on how to configure WorkflowGen delegated authentication with Microsoft Entra ID (ME-ID) authentication via the Microsoft Identity Platform v2.0 or API endpoint v1 providers, and will show you how to set up a working WorkflowGen instance that uses ME-ID to authenticate your users.

Prerequisites

• Make sure to have a licensed copy of WorkflowGen installed and running on an IIS web server in HTTPS secure connection mode.

• You must be a WorkflowGen Administrator.

• Make sure to have ME-ID Administrator access to be able to configure ME-ID.

• Make sure to have provisioned an existing ME-ID user that you can authenticate with WorkflowGen and that the user has WorkflowGen Administrator permissions. This is important because once you've activated the delegated authentication with ME-ID, you'll still need to be able to manage the WorkflowGen web application.

• AES encryption mode and its key are required for the authentication to work.

The configuration of ME-ID is done in two parts. First, you have to register the WorkflowGen web application and link it to your instance of WorkflowGen; then, you have to register the WorkflowGen GraphQL API in order to be able to register other custom applications to access it.

1. In the Azure portal, click App registrations in the Azure services section.

2. Click New registration, and fill in the properties form:

   • Name: WorkflowGen Web app

You should now see the WorkflowGen Web app application registration's overview page.

Now, you have to generate a client secret to be used by the WorkflowGen OIDC authentication module.

1. Click Add a certificate or secret.

2. In the Client secrets section, click New client secret.

   • Description: My secret, or something to know that this is the client secret.

In order for the communication between the WorkflowGen instance and ME-ID to work, you need to add one more authorized redirect URI to the WorkflowGen Web app application registration.

1. Under Redirect URIs on the application's overview page, click Add a Redirect URI.

2. Enter the following information:

   • Redirect URI: https://<workflowgen url>/auth/logout/return 📌

In order to expose the WorkflowGen GraphQL API, you need to add a new application registration in ME-ID that will represent it. To do this:

1. In the Azure portal, click App registrations in the Azure services section.

2. Click New registration, and fill in the properties form:

   • Name: WorkflowGen GraphQL API

You've now successfully registered the WorkflowGen GraphQL API application in ME-ID.

1. Click Expose an API.

2. To the right of Application ID URI, click Set and enter the URI https://<workflowgen url>/graphql 📌 Example: https://mycompany.com/wfgen/graphql

You should now have a new scope defined (e.g. https://<workflowgen url>/graphql/default).

1. On the WorkflowGen Web app application registration page, click API permissions.

2. Click Add a permission, then select the tab My APIs.

3. Click the WorkflowGen GraphQL API

You should now have all of the information you need to configure your WorkflowGen instance to delegate authentication to Microsoft Entra ID Here's a review:

• A client ID. This is the application (client) ID of the WorkflowGen Web app application registration in ME-ID. You can find it on its Overview page.

• A client secret. This is the secret previously generated in step 2 for the WorkflowGen Web app.

By now, you should have all the information needed to link your WorkflowGen instance to ME-ID.

Now, you have to configure WorkflowGen to delegate its authentication to ME-ID.

1. Open the WorkflowGen web.config file and add and/or update the following properties under <appSettings> For Microsoft Identity Platform v2.0 (recommended):

   For Azure v1:

   ✏️ Note: Check session iFrame (e.g. ApplicationSecurityAuthCheckSessionUrl) is not supported in Microsoft Identity Platform v2.0.

WorkflowGen should now be linked to your ME-ID. The last thing left to do is to configure a few more options in order to finish the internal wiring of WorkflowGen so that it can delegate its authentication.

WorkflowGen uses an internal session token to manage the user session and identify the current user for all the HTTP requests made to the web application after the user has logged in to ME-ID. In order to generate a session token, you need to add a few more settings to the web.config.

1. Open the WorkflowGen web.config file and add and/or update the following property under <appSettings>:

2. Replace <SECRET> with a custom value that can't be guessed, such as a UUID or a complex password.

The secret will be only accessible inside your instance of WorkflowGen, so when generating a session token, WorkflowGen will sign it with this secret in order to check the validity of all session tokens passed to it.

You now need to activate the delegation by replacing the authentication system in IIS and pointing WorkflowGen's modules to the correct authentication module.

1. In IIS Manager, click on the WorkflowGen website in the tree view.

2. Click the Authentication button.

3. Enable Anonymous Authentication, and disable all other authentications.

Certain sub-applications need to have their authentication checked by the special Advantys.Security.JWTAuthenticationModule WorkflowGen authentication module, but certain other sub-applications (such as /wfgen/auth, /wfgen/hooks and /wfgen/scim) should not because they are either public or aren't part of the global authentication system.

1. Add the following property to the WorkflowGen web.config file:

2. If you've developed custom web forms with their own \bin folders, you have to copy the following .NET assemblies and dependency libraries from \wfgen\bin to each custom web form's \bin folder (\wfgen\wfapps\webforms\<custom webform>\bin):

By default, the only recipient of the access token is the WorkflowGen GraphQL API application. This means that the access token can only be used to send queries to the GraphQL API only. In order to use the same access token to call your own APIs from WorkflowGen (e.g. web forms), you will need to perform the following steps in your Azure portal, and then modify the WorkflowGen web.config file.

1. In the Azure portal, click App registrations in the Azure services section.

2. Click New registration, and fill in the properties:

   • Name: My APIs

1. Click Expose an API.

2. To the right of Application ID URI, click Set and enter the URI api://my-apis.

3. Click Save.

1. Click Manifest.

2. Find the appRoles JSON property and add the following JSON object to the JSON array:

   ✏️ Note: Replace <NEW ID> with the value generated by the [guid]::NewGuid().ToString() PowerShell command or use any GUID generators.

1. On the WorkflowGen Web app application registration page, click API permissions.

2. In the Configured permissions section, click Add a permission.

3. Click My APIs, then select the My APIs

For each of your automated applications in Azure (e.g. server-side script, background service, or application) that requires access to the My APIs application, do the following:

1. Go to the application's registration page, then click API permissions.

2. In the Configured permissions section, click Add a permission.

3. Click My APIs, then select the My APIs application in the list.

Open the WorkflowGen web.config file, add and/or update the following application settings, then save the file:

The WorkflowPage class in the WorkflowGen.My library provides a public CurrentUserAccessToken method to easily retrieve the current user's shared access token that can be used to query the GraphQL API and your third-party APIs. See the snippet code below.

WorkflowGen only supports requests to the SOAP API using classic authentication methods. If you still need to use this API, you have to perform some additional steps to configure it properly:

1. Create a new separate WorkflowGen directory (i.e. users and groups) for the SOAP API users.

2. Provision it with users and groups as needed.

3. In IIS Manager, enable the Basic authentication method for the \wfgen\ws application.

Microsoft Entra ID (ME-ID) supports , an extension draft standard, in addition to the core OpenID Connect standard. This standard defines the rules to handle SSO session of the provider from the client. An example use is that if a user logs out of their ME-ID session from any device, a regular web client will receive a message that enables it to remove the same user's local session. WorkflowGen supports this feature when activating delegated authentication with ME-ID.

This table lists all configurable options in WorkflowGen that you can use to customize your authentication experience; these are located in the WorkflowGen web.config file.

If the WorkflowGen User Portal or Administration Module is displayed without the main header menu, this feature will not work. For example, this scenario could occur when the portal home page or a request follow-up form is displayed inside an iFrame in an external solution.

If for some reason you can't register the WorkflowGen GraphQL API application and you don't need GraphQL API authentication configured with the provider, you can avoid creating the registration and configure WorkflowGen with the Microsoft Graph API instead, which is included by default in all application registrations. To configure it, you only have to change some configuration options in the web.config file:

1. Change the ApplicationSecurityAuthAudience key to the Microsoft Graph API URL, e.g.https://graph.microsoft.com.

2. Set the ApplicationSecurityAuthDecodeAccessToken option to N.

Overview

This section provides instructions on how to configure the optional Read Scale-Out feature, which allows load balancing of SQL Database read-only workloads using a read-only replica rather than a read-write replica. For more information on this feature, see the Use read-only replicas to offload read-only query workloads Microsoft article.

Prerequisites

• Make sure to have either a Premium or a Business Critical service tier.

• You must have permissions to make changes to the database in the Azure portal.

Read Scale-Out configuration

Step 1: Enable the Read Scale-Out feature in PowerShell

1. Install or update the Azure PowerShell module in PowerShell by running the following commands:

   For more information, see the Microsoft article.

2. Log in to your Microsoft Azure account in PowerShell by running the following command:

   If you encounter any security issues with the Microsoft Azure sign-in process, then you must manually add https://login.microsoftonline.com/ and all related websites' URIs to the Trusted sites zone in Internet Explorer's Internet Options.

3. Enable the Read Scale-Out feature in PowerShell by running the following command:

   • Replace <resource group> with the resource group name.

   • Replace <server name> with the server name (e.g. workflowgen.database.windows.net

You can also enable Read Scale-Out feature using the .

1. Go to the Database section on the Configuration Panel General tab. In the Master database connection string field, add the ApplicationIntent=ReadWrite parameter to the existing connection string and click Test to test the database availability. Here's an example of a connection string:

3. In the Read-only database connection string field, add (or edit) the connection string with the new ApplicationIntent=ReadOnly parameter, and click Test

Overview

This section provides instructions on how to configure an Azure SendGrid SMTP with WorkflowGen.

Create the SendGrid account in the Azure Portal

The SendGrid account must be created in the Azure Portal. See Create a SendGrid Account for more information on how to create a SendGrid account. Once you've completed the configuration, you'll have:

• The server name (e.g. smtp.sendgrid.net)

• The username (e.g. apikey)

• The generated password

• Port 25 or 587 set for TLS connections and explicit SSL connections.

For more information about the SendGrid SMTP integration, see the Twilio article.

To set up the connection between WorkflowGen and Azure SendGrid SMTP:

1. Go to the General tab in the Configuration Panel.

2. In the SMTP section:

   • Choose Server as the delivery method.

Overview

As of WorkflowGen server version 7.16.0, you can generate a universal link to simplify the Microsoft Entra ID (ME-ID) login process for your WorkflowGen Plus mobile app users.

Base URL

• protocol: workflowgenplus://

• hostname: auth.init

Parameters

You'll need to specify the following parameters:

• provider: ms-identity-v2

• server_address: Your WorkflowGen application URL, whose value must be URL encoded (e.g. https://mycompany.com/wfgen)

• client_id

The universal link should follow this format:

This section provides instructions on how to configure Microsoft Entra ID (ME-ID) with a single-page application (SPA) so that users can authenticate through it and make requests to the WorkflowGen GraphQL API. This configuration is done in three steps: registering your SPA, granting access to the API, and setting some redirect URLs.

• Make sure to have a licensed copy of WorkflowGen installed and running on an IIS web server in HTTPS secure connection mode.

• Make sure to have administrative access to ME-ID to be able to configure it properly.

Prerequisites

• Make sure to have a licensed copy of WorkflowGen installed and running on an IIS web server in HTTPS secure connection mode.

• Make sure to have Microsoft Entra ID (ME-ID) administrator access to be able to configure it.

• Make sure to have provisioned an existing ME-ID user with which you can authenticate to WorkflowGen so that you can use the application afterwards.

• Make sure to have successfully configured delegated authentication to ME-ID with the Microsoft Identity Platform v2.0 provider on your WorkflowGen instance following the instructions in the section with the WorkflowGen GraphQL API application registered as well.

This configuration is done in three steps. First, you have to register a new native application in ME-ID. Then, you have to give the application the necessary permissions to access the WorkflowGen GraphQL API. Finally, you have to register the correct callback URLs that will redirect within the native application.

1. In the Azure portal, click App registrations in the Azure services section.

2. Click New registration, and fill in the properties:

You've now successfully registered your WorkflowGen CLI native application in ME-ID.

1. Click API permissions.

2. In the Configured permissions section, click Add a permission.

3. Click My APIs, then select the WorkflowGen GraphQL API application in the list.

Take note of the information you'll need later on:

• A client ID: This is the application (client) ID in the Overview section of your application registration.

• A tenant ID: This is the directory (tenant) ID in the Overview section of your application registration.

You'll need to give this information to the users who will be using the WorkflowGen CLI.

The configuration of non-interactive mode is the same as in the section.

This section provides instructions on how to create and configure your Azure Load Balancer feature. From the Microsoft article:

With Azure Load Balancer you can scale your applications and create high availability for your services. Load Balancer supports inbound and outbound scenarios, provides low latency and high throughput, and scales up to millions of flows for all TCP and UDP applications.

Load Balancer distributes new inbound flows that arrive on the Load Balancer's frontend to backend pool instances, according to rules and health probes.

Additionally, a public Load Balancer can provide outbound connections for virtual machines (VMs) inside your virtual network by translating their private IP addresses to public IP addresses.

Create a Basic load balancer following . Once you've completed the steps, you'll have:

Mobile applications must use an approach similar to that of regular web applications, which is called Authorization Code Flow with Proof Key for Code Exchange (PKCE). The main difference between this and the classic Authorization Code Flow is that the mobile application doesn't get a client secret, but instead exchanges a pair of codes to prove the origin of the authentication attempt. The issue is that a mobile application can't be trusted with a client secret because it's distributed directly to users and is therefore no longer under the developer's control, and the sources can be decompiled and analyzed to find secrets like this.

This section provides instructions on how to configure Microsoft Entra ID for mobile apps so that your mobile users can benefit from delegated authentication to ME-ID as well.

• Make sure to have a licensed copy of WorkflowGen installed and running on an IIS web server in HTTPS secure connection mode.

Overview

As of WorkflowGen version 7.22.5, Remote Approval supports the use of a Microsoft 365 user account in Exchange Online using Modern authentication to receive and process approval emails.

Modern authentication uses the industry-standard OAuth2 protocol for authorization. For this, OAuth2 provides a type of grant called Client Credentials that simply exchanges a client ID and secret for an access token that will be used to retrieve and send approval emails from the Office user account mailbox.

This section provides instructions on how to configure Remote Approval to integrate with Exchange Online using Modern authentication. First, you'll need to configure a new application in the Azure portal; then, you'll need to configure the Remote Approval settings in WorkflowGen.

Prerequisites

• Make sure to have a licensed copy of WorkflowGen installed and running on a server.

• Make sure to have administrative access to WorkflowGen.

• Make sure to have administrative access to Microsoft Entra ID to be able to configure it properly.

• Make sure to have turned ON Modern authentication for Outlook client in the Microsoft 365 admin center. See the Microsoft article for more information.

• Make sure to use a Microsoft 365 user account that has a valid Microsoft 365 license and read/write permissions to the Exchange Online mailbox. This account will be used for the Remote Approval username and default reply-to email settings.

1. In the Azure portal, click App registrations in the Azure services section.

2. Click New registration, and fill in the properties:

   • Name: Your Remote Approval app name (e.g. WorkflowGen Remote Approval

You've now successfully registered your Remote Approval app in ME-ID.

1. Click API permissions.

2. In the Configured permissions section, click Add a permission.

3. Click APIs my organization uses, then search for Office 365 Exchange Online.

1. Stay within the API permissions section.

2. If you're a Microsoft 365 administrator, click Grant admin consent for to grant consent to the application.

3. If you're not a Microsoft 365 administrator, then you'll need to ask one to grant admin consent for your application in their Azure Portal.

1. In the Applications menu, click Certificates & secrets.

2. In the Client secrets section, click New client secret and enter the following properties:

   • Description: client_secret

1. In the Applications menu, click Branding.

2. If needed, update your application name, company logo, home page URL, terms of service URL, or privacy statement URL.

3. Click Save when done.

Here's a review of the information you'll need:

• The Remote Approval application (client) ID, which can be found in the registered application overview section.

• Your directory (tenant) ID, which can be found in the registered application overview section.

• A client secret

You're now ready to configure your Remote Approval settings in WorkflowGen.

1. Open the Configuration Panel from the WorkflowGen Administration Module home page.

2. On the Remote Approval tab, fill in the form for the Incoming mail server section:

   • Type: Exchange Online - Modern Authentication

Overview

This section presents some pointers on setting up and managing a Kubernetes cluster tailored for WorkflowGen in Azure.

Creating a new cluster

To create a new cluster that supports Linux and Windows workloads, see the Deploy a Windows Server container on an Azure Kubernetes Service (AKS) cluster using Azure CLI Microsoft article, which includes step-by-step instructions on how to create the cluster. Follow all the instructions, including creating a Windows node pool. At the end, you should have at least two nodes: a Linux node and a Windows node.

You can use Microsoft Entra ID (formerly Azure Active Directory) to authenticate and authorize users in the cluster. See the Integrate Microsoft Entra ID with Azure Kubernetes Service (AKS) using the Azure CLI (legacy) Microsoft article for more information.

Managing Windows and Linux nodes

By default, AKS doesn't restrict further Windows nodes from preventing Linux deployment on them. It's recommended to use taints and tolerations to avoid problems with Linux deployment being scheduled to Windows nodes. The following is an example of how you can use taints and tolerations to manage hybrid deployments.

Taint all Windows nodes

Tainting all Windows nodes will prevent any deployment to Windows nodes from being scheduled except when it has the required toleration. Therefore, for many Linux Helm charts that don't have a node selector, the deployments to Linux nodes will automatically be scheduled. Google Kubernetes Engine does this by default. Execute the following command to taint a Windows node:

To be able to deploy Windows pods to Windows nodes, you have to use a combination of tolerations and node selectors in your deployment specification. For example, consider this WorkflowGen deployment:

In order for it to be scheduled to a Windows node, you would have to add the following to the template's spec:

This adds a toleration for the taint that you've just added to the node and tells the Kubernetes scheduler to select a Windows node when scheduling the WorkflowGen pods.

You can also simplify this by creating a RuntimeClass object that holds this information and referencing the runtime class in your Windows deployments:

Apply this file:

Then, add the following to the template's spec:

As you can see, this RuntimeClass also ensures that the deployment will be on a Windows LTSC 2019 (1809) node.

There are two things that you must consider for update management: the Kubernetes version and the operating system update. For information on upgrading the cluster to a specific Kubernetes version, see .

Applying security patches and updating operating systems differ for Linux and Windows nodes. To get started with operating system updates, see for more information. (Don't worry about the title of the article; there's a paragraph about Windows updates in it.)

You can use an autoscaler in AKS to automatically scale up the number of nodes in your cluster based on rules to keep up with demands. See for more information. This feature pairs well with the Kubernetes horizontal pod autoscaler. See for more information.

You can also use Azure Container Instances to quickly scale up your cluster for a short period of time. See for more information.

Overview

This section provides instructions on how to create and configure your Azure SQL database.

Create the Azure SQL database

The Azure SQL database instance has to be created in the Azure Portal. See the Quickstart: Create a single database - Azure SQL Database Microsoft article for more information on how to create the database. Once you've completed the instructions, you'll have:

• The name of the Azure SQL server

• The credentials of the administrator account

• A server-level firewall rule for your IP address server

• The name of the Azure SQL database.

1. Connect to your Azure SQL database instance with the administrator account you created by using the or .

2. You have to create a SQL Server user account with db_datareader and db_datawriter permissions. See the Microsoft article, or run the following script in the SQL Database Query Editor or SQL Management Studio (the master database must be selected):

The Azure SQL database can also be created via Azure CLI scripts. To do this:

1. .

2. Copy the WorkflowGen database create.sql script to the C:\Azure\setup\sql folder. If you want to change the path, you'll have to edit the $sqlScriptPath variable in the following script as well.

The following scripts create the SQL Server and SQL Database. The SQL database admin password variable ($sqlAdminPassword) must be updated; the resource group name ($resourceGroup), pricing tier ($sqlServiceObjective), and SQL script path ($sqlScriptPath) should be updated as well. (For more information on the pricing tier, see .)

• Option A: Contained database mode The following script creates the database user (wfgen_user) in a contained database. The SQL database user password variable ($sqlUserPassword) must be updated.

  ✏️ Note: Don't run the Remove my public IP script if you need access to the database from your desktop or if your WorkflowGen server is not hosted by Azure.

Open the WorkflowGen web.config file and add the following node under <connectionStrings>:

• Replace <server name> with the server name (e.g. workflowgen.database.windows.net).

• Replace <database name> with the database name (e.g. WFGEN).

In some cases, you'll want to perform a specific task that can be automated but needs access to the WorkflowGen GraphQL API; this use case is often in the form of a server-side script or application (e.g. background service, daemon, curl , Postman, etc.). For this, OAuth2 provides a type of grant called Client Credentials that simply exchanges a client ID and client secret for an access token. There is no ID token since it's not part of the OpenID Connect standard and there's no user involved.

This section provides instructions on how to configure Microsoft Entra ID (ME-ID) for a server-side script or application to have access to the WorkflowGen GraphQL API. First, you'll need to register a new web application in ME-ID; then, you'll need to configure a new application in your WorkflowGen web server.

Azure Files is a cloud-based service that provides a file storage backing service for WorkflowGen instances that are hosted on Azure cloud or on-premise via a file share using the standard SMB protocol. This service provides different great options for data access, sharing, synchronization, and redundancy for use in single or multiple WorkflowGen instance scenarios.

For more information about Azure File benefits or use cases, refer to Microsoft's guide.

The following section provides recommendations and instructions on how to configure an Azure Files share to use in WorkflowGen.

Before choosing Azure Files as your primary file storage backing service for your WorkflowGen, there are a few performance configuration scenarios to consider for your data storage:

Overview

This section provides instructions on how to configure the WorkflowGen Azure AD synchronization connector, which relies on Microsoft Entra ID user provisioning features. Users and groups are automatically updated (pushed to WorkflowGen) by ME-ID (every 20 to 40 minutes) using the SCIM v2 protocol.

As mentioned, it's ME-ID that pushes the data to WorkflowGen. The nature of the protocol doesn't allow WorkflowGen to update in any way the directory in ME-ID. In other words, it's ME-ID that queries WorkflowGen for information, not the other way around. This means that ME-ID is the only source of truth for users and groups for the system.

In the instructions, substitute <workflowgen url> with the domain and path to your WorkflowGen instance; for example, localhost/wfgen or mycompany.com/wfgen.

Prerequisites

• Make sure to have a working WorkflowGen instance within a network reachable by ME-ID with the HTTPS (recommended) or HTTP ports opened.

• Make sure to know the address of the instance.

• Make sure that the WorkflowGen instance is running.

• Make sure that the SCIM application is properly installed and configured. For instructions on how to do this, see in the section in the WorkflowGen Technical Guide.

• A P2 license must be activated in the ME-ID tenant.

This section provides instructions on how to define a new directory that will be used by ME-ID to synchronize users and groups. Once you've made sure you've met the prerequisites, you can proceed with configuring WorkflowGen to receive information from ME-ID.

1. In the WorkflowGen Administration Module (https://<workflowgen url>/admin), click Directories, then click New directory on the Directories screen.

2. Enter a name and a description for the directory.

3. From the Directory connector drop-down list, select

This section provides the steps for configuring a typical enterprise application with ME-ID in order to provision your WorkflowGen instance with users and groups.

In order to provision WorkflowGen, you have to register it in the Microsoft Entra admin center, which is done by adding a new enterprise application. To do this:

1. In your Azure portal, go to the Enterprise applications page, then click New application.

2. In the Browse Microsoft Entra Gallery page, click Create your own application, then select Integrate any other application you don't find in the gallery (Non-gallery)

3. Enter a name for the application. Typically, you'd want to give it a name like

You can now proceed to configure the ME-ID application to provision WorkflowGen.

Click Provision User Accounts on the application page, then click Get started on the Overview page. All of the remaining configurations will be done here.

To set up the connection between WorkflowGen and ME-ID:

1. Choose Automatic provisioning mode.

2. Click Admin Credentials. In the Tenant URL field, add your WorkflowGen SCIM URL https://<workflowgen url>/scim (e.g. https://mycompany.com/wfgen/scim).

   ✏️ Note: If your WorkflowGen base domain already points to the WorkflowGen instance, don't include the wfgen

Two new sections should now appear: Mapping and Settings. You'll need to change some mappings in order to correctly match the corresponding data in WorkflowGen, and to reduce the possibility of errors.

Groups

Click the option that contains Groups to change the mapping for groups. Then, in the new page, go to the Attribute Mappings section and keep only the externalId, displayName, and members mappings set to customappsso. You'll also need to change the mapping of externalId to ME-ID's objectId if it is not correctly mapped already. This will prevent two different groups from being provisioned with the same externalId. This attribute must be unique.

You also have the ability to customize which operations should be executed in the WorkflowGen directory. If you're starting from scratch, you should leave Create, Update, and Delete enabled to make sure that Azure can perform any operation it needs to keep WorkflowGen in sync with ME-ID.

The final mapping should resemble the following table. If you have any additional mappings that aren't listed here, you should delete them, because they won't be mapped in WorkflowGen.

Once you've set all of the group mappings, click Save again.

Users

You also need to modify the user mappings. To do this, return to the Provisioning options for the enterprise application, then click the button for user mappings in the Mappings section.

In the Attribute Mappings section of the new page, you only need to change the mapping of externalId to ME-ID's objectId.

You also have the ability to customize which operations should be executed in the WorkflowGen directory. If you're starting from scratch, you should leave Create, Update, and Delete enabled to make sure that Microsoft Entra ID can perform any operation it needs to keep WorkflowGen in sync with it.

The final mapping should resemble the following table. If you have any additional mappings that aren't listed here, you should delete them, because they won't be mapped in WorkflowGen.

Once you've set all of the user mappings, click Save.

You're now ready to launch the synchronizations of users and groups with your WorkflowGen instance. To do this, go to the Settings section of your enterprise application's Provisioning page.

If you want to synchronize only a subset of your ME-ID users and groups, select the Sync only assigned users and groups scope, then manually assign them to this application in the directory. To do this, go to the application's Users and groups section and manually add your users there.

You can also configure the application to synchronize all of your directory's users and groups. In this case, select the Sync all users and groups scope.

Once you're ready, change the provisioning status to On, then click Save.

If you already have a synchronization with a classic AD, this section provides instructions on how to migrate your WorkflowGen users to your new Microsoft Entra ID without having to delete then re-create them.

First, it's important to understand how Microsoft Entra ID synchronizes your directory through the SCIM connector before going ahead with a migration. In this guide, we've changed the default mapping between ME-ID object properties and SCIM properties. One of these is the externalId SCIM property, which represents a unique identifier from an external system, so it must be opaque for WorkflowGen. This guide has you change this mapping from displayName in ME-ID to objectId. In WorkflowGen, externalId maps to a user's systemIdentifier property; therefore, the objectId value from ME-ID is being provisioned into the systemIdentifier value in WorkflowGen.

Second, ME-ID begins the synchronization by interrogating the SCIM connector to find existing users. It begins by sending GET requests with its objectId values. Since WorkflowGen doesn't have any Id that corresponds to ME-ID's objectId, it will always fail with a 404 NOT FOUND error. Then, it sends GET requests but with a filter on externalId, and this time, it will find users in WorkflowGen if their systemIdentifier matches a user's objectId in ME-ID.

1. Deactivate the classic Active Directory synchronization connector.

2. Create a new Azure SCIM v2 directory connector.

3. Move the users and groups already in Active Directory from other existing WorkflowGen directories to the SCIM directory.

This example contains an algorithm that links users and groups to ME-ID:

This example contains an algorithm that links only users to ME-ID:

If you encounter this issue, it might be because the users and groups are outside the scope of the synchronization. The reason could be that you didn't assign users to the enterprise application and you selected a scope of assigned users only. To resolve this, assign users to the enterprise application by going into its Users and groups section. You can also change the scope of the synchronization to all of the directory's users and groups by editing the enterprise application's synchronization settings.

Another possible cause might be related to other configurations in your Microsoft Entra ID. For more troubleshooting steps, see the Microsoft article.