Importing LDAP Users

<< Click to Display Table of Contents >>

Navigation:  Bizagi Studio > Security definition > Work Portal Security > Synchronizing users >

Importing LDAP Users


Disregarding the selected Authentication type for your Work Portal login, you may choose to configure a schedule in Bizagi to import and synchronize users from your LDAP Server into Bizagi.


With this option, Bizagi will run a daily job to keep up-to-date the accounts' information (residing in an LDAP Server in your organization).

Keep in mind that passwords will be queried according to the selected Authentication type (meaning, that if you choose LDAP or Windows Authentication, Bizagi will not store any passwords).


Before you start

To set user synchronization using LDAP make sure that you have the following:

LDAP URL in LDAP format. (LDAP using SSL is supported).

Username and password be able to read user's information.


What you need to do in Bizagi

To both set and test the LDAP synchronization in your project, you need to enter the configuration details to your LDAP server, such as: URL, connection credentials and import settings or mappings.


This is done easily through three tabs, in these steps:


1. Entering the connection and import settings

2. Specifying attribute mappings

3. Defining default values (if any)

4. Testing and saving your configuration

5. Restarting the Scheduler service



You may also choose to modify later these settings for a specific environment in your project (Test or Production environment).

To review or modify LDAP synchronization in a given environment, use Bizagi Management Console.


1. Entering the connection and import settings

This initial configuration is done in the first tab called Basic configuration.

To do this, first enable the LDAP synchronization by marking the Enabled checkbox.


Then, make sure you fill out both the connection and import settings as described below:






Specify the URL path to access the LDAP server (LDAP URL format). LDAP using the SSL protocol is supported.


URL can start in any of these ways:




Specify a username and its domain, to be used as the authenticated user performing the synchronization.

Such user needs read access to these definitions.


Specify the password for the domain's username used as the authenticated user performing the synchronization.

Synchronization hour

Define an hour of the day in which the Scheduler will perform the LDAP synchronization.

Allowed values for this field are 0 to 23.


If you wish for Bizagi Studio to perform the initial synchronization immediately, then you may input the current hour in which your server is at. For example, if it is currently 14:35, then you may input 14.


If you are using Automation Service (cloud), the hour of the synchronization is based on UTC.

Import settings


Input a filter to import only the proper accounts into your project (according to an LDAP attribute criteria).

It is strongly recommended to use and set a filtering condition in order to import the proper set of users (especially when testing the configuration).

View more information about filter options at LDAP attributes.


Specify the domain name to which the users will be registered in Bizagi's user entity (WFUser).

User account identifier

Choose the LDAP attribute which identifies in an UNIQUE manner each account. For example, sAMAccountName is the common LDAP attribute corresponding to an user's account name.



If the the "domain" field in the import setting section is left empty, then any user whose LDAP data doesn't include a domain will not be synchronized. If you want to synchronize these users you can include a Default value for the users that don't have an LDAP domain.





In this example, we set all these values:





Note that you may define the connection and all relevant LDAP import settings separately for each of your different environments (Development, Test and Production).


An initial deployment (the very first one) will publish this configuration to each environment.

Henceforth, changes to the LDAP import settings need to be done locally (managed separately) in each environment.


We strongly recommend applying a filter to exclude records that have empty or null values for the following fields: contactEmail, fullName and the account identifier field.


2. Specifying attribute mappings

LDAP accounts information is synchronized into Bizagi's WFUser System Entity.

By specifying attribute mappings you define in which WFUser attributes is the incoming information stored.

Move on to the next tab called Attribute mappings and make sure you add the necessary mappings for your WFUser attributes.


To do this, first click on the Add Mapping button.

Select attributes from the WFUser Entity and match them to an LDAP attribute, which has the incoming information:




You can map to any attribute of your WFUser. The only exception is the idUser attribute, this ensures the integrity and consistency of your data.

Note that in this example we illustrate mapping the mail and name attributes since these 2 are explicitly required in Bizagi (contactEmail and fullName).


The following is the list of the default values available to be mapped.

The attribute used as the account's identifier is mandatory, it cannot be null.



Data type




Sets the email of the user. It is a mandatory field (cannot be null).



Identifies if the cases should skip allocation rules in development or test environments when created by this user



Identifies if the user has the delegation enabled



Identifies the domain of the user. It is a mandatory field (cannot be null).



Identifies if the user is enabled in Bizagi



Identifies if the user is legible for allocation of tasks



Sets the full name of the user.



Identifier of the Area of the user. Table AREA. *



Identifier of the user in the Table WFuser.*



Identifier of the user in the Table WFuser.*



Identifier of the Location of the user. Table LOCATION. *



Identifier of the Time zone of the user. Table BATIMEZONE. *



Identifier of the working time of the user. Table WORKINGTIMESCHEMA. *



Identify the ID in the section Language IDs



Identifies if the user sholud receive emails sent by the solution, for automatic and customized notifications.



Sets the username. This field is mandatory (cannot be null)



Configures the landing page of the user when they log in. It is used when the user is associated to a Stakeholder, otherwise the default page is the Inbox. Choose from:

1. Automatic (default): Me if associated to a Stakeholder of Inbox if not.

2. Inbox:  Always opens the Inbox

3. Me: Always opens the Me page.


* Filed available to for on premises installations, given that the identifier is retrieved from the database.



It is required that you map:



domain: Bizagi recognizes domains in strings such as "domain\username" and "username@domain"


Quick facts that will help you design the synchronization

1.None of the three above fields should be NULL or blank.

2.The username + domain combination defines uniquely users in Bizagi (no two users can have the same username + domain combination). This is also important to bear in mind when doing the sync, because finding a same username + domain will have Bizagi assume there is an update to an existing record.

3.Usually username is taken from userPrincipalName or sAMAccountName.

4.When Bizagi receives a value (identifier) that is not valid, it is ignored.

5.Objects not listed in the table above should be ignored as those fields have been deprecated (i.e. offlineForms)


3. Defining default values (if any)

This step is optional and recommended to define any default values for the WFUser attributes. Move on to the next tab called Default values and add any necessary default values for your WFUser attributes.

To do this, first click on the Add Default value button.

Select attributes from the WFUser Entity and assign to them a value:





Do NOT specify that the enabled attribute is set to true, unless you are completely certain that your current license will support the number of imported users.

Keep in mind that if the total number of active users is greater than the number of licensed users, then the Work Portal will stop working.


4. Testing and saving your configuration

Once you have finished your configuration, you may click the Test button to see your synchronization results.

Notice that this can take a while if you have a large number of users and therefore, it is recommended to use a filtering criteria.


You will be shown the records found in last tab called Test results:





Testing the configuration does not imply that an immediate synchronization is carried out at Bizagi's database.

This is only for testing purposes and not persisted, since the Scheduler service will be in charge of executing your final configuration.


Finally, save your configuration:




5. Restarting the Scheduler service

As noted before, take into account that LDAP synchronization can be tested directly in Bizagi Studio.

However, the actual synchronization of the LDAP accounts (objects) is carried out by the Scheduler service in your project.

Therefore, to initialize this synchronization and actually see your users in your Work Portal (project's execution), you will need to restart the Scheduler service.

To start the import and synchronization, take into account that you need to restart the Scheduler.


The Scheduler's job will start to execute the synchronization at the defined hour.

When this has been completed, the LDAP users will be automatically created as Bizagi users.


To check for information about the executed synchronization (inserted and updated values), you may check the detail Bizagi saves in the Scheduler's trace.

Detail for this, would begin the line as INFO_LDAP at the Scheduler’s log file.

For more information about enabling traces, refer to Error control and diagnostics.



When synchronizing your users, Bizagi will only import as active, the first imported users according to the number of supported users by your active license.


If a user is no longer found at the LDAP server, then Bizagi will disable that user (a logical deletion; not physical) in its import as well.