As always it's best to use an example or problem for explanation: Let's say we have a few groups in Active Directory that are used to authorize the use of applications.
So if you're in the group Photoshop you can install Photoshop on your client computer.
There is an update available that needs to be installed to the computers of everyone that uses Photoshop.
We could let someone check Active Directory which users are in the Photoshop group but that means giving people permissions
and a training about using Active Directory Users and Computer.
We can also let Nintex get that data for us and store it in a list, or even e-mail the people directly.
Create a simple SharePoint list for this example with the following fields:
- Title, single line of text
- Results, multiple lines of text, plain text
Drag the following actions on the canvas:
- Build String
- Query LDAP action
- For each
- Build String
- Update Item
The following variables need to be created
- SamAccountNames; Collection
- SamAccountName; single line of text
- Results; single line of text
- Groupname; single line of text
As in most organizations the name of an Active Directory group tells if the group is global, domain local, security or distribution.
We don't want the users to be bothered with this so let the workflow configure the correct name.
All groups need the syntax DL_Sec_ for their name, we use a Build String action to configure this.
- In the field Text add DL_Sec_;
- From the Insert Reference button add the ItemProperty Title;
- Select in the Store result in the variable Groupname;
- Click on Save;
Configure the Query LDAP action to retrieve all users that are member of the AD group.
- Select the path to the LDAP environment, if you have separated OU's for users and groups select the level where both are discoverable.
This way the action can get to the group and also retrieve the corresponding users.
- Create the Query, in this example we want the objectcategory user when the user is member of the workflow variable groupname:
Don’t forget to add the rest of the path to the groups location
- In the property to retrieve field type samaccountname and click on Add
- Select the collection variable SamaccountNames to store the property and click on Save.
If configured correct you will receive the users that are member of the group in a collection variable.
You could choose for a single line of text but we prefer a collection.
Downside of a collection is that you can't store it directly in an Update item or Set field value action.
We first need a For Each action.
Open the action and select the SamaccountNames for the field Target collection.
For the field Store result in select SamaccountName.
Add a Build string action into the For each action to rebuild all samaccountnames into one variable.
You could also add a Send notification action to email all users, we then needed to retrieve the email addresses from the users.
Add the variables SamaccountName and Results to the text field.
Select Results as the variable to store the results in.
Last step is to update the item with the results.
Select the Current item from the Update field.
Select the field Results to update
From the Equals option select the Workflow Data Results
Save the Action
Save and publish
Save and publish the workflow.
When we test the workflow we receive the accountnames from the users of the AD Group.
This is off course just a simple example of using the Nintex Workflow Query LDAP action.
In the comments you can add other examples, maybe we will create an example of these.
For more information at the LDAP Query options and how to filter have a look at : http://social.technet.microsoft.com/wiki/contents/articles/5392.active-directory-ldap-syntax-filters.aspx
If you liked this article be sure to have a look at Nintex Workflow User's Guide for more tips, tricks and hands-on assignments.