In one of the workflows we are using we send emails out to a number of users. This could be anywhere from a single user up to a handful or more. Currently we query a group in a specific OU and return a list of names. Those names are popped into the TO line of an email and sent out. This works OK until recently a user was added that had the same first and last name of another user and despite them being in 2 separate OUs both users were emailed instead of one.
So it became clear that a more precise way of sending emails needed to be done. AS the Administrator I'm not as familiar with Nintex actions as the developers but they are out of office for a few days and this is something of a security issue.
Can a collection be passed into the QUERY LDAP action such that the query becomes
or is there a query that can accept a delimited string of users to pull back a string of email addresses? I've not been able to find this capability in the ldap query syntax and it doesn't sound too efficient.
Solved! Go to Solution.
What if instead of returning the names from the group, you return the samaccountname of the user. This is the users ID, which would be unique. That would resolve to the correct user in the notification.
Currently we are using an LDAP Path to the Roles OU and in the query we are using:
where sp_groupname2 is the name of the AD group
when output is set to samaccountname it returns the name of the AD group
when output is set to member it returns the name of the AD group members
So if there is some way of saying..don't send me the fqdn of each member but instead send me only their emails, that would be ideal as it would avoid having to do more processing downstream.
Ok, dug into this a little bit more. If you're querying on the Group in LDAP, you can only return names. However what you can do is query on the users, and then look for users that are part of that group, and then return the samaccountname, which should be unique for each user. After "memberOf" you need to list the full path in LDAP to the group.
Ok, did some more digging. Assuming you only have the group name here is how you would get the distinguished name (which is the group path in LDAP), and then feed that into another query to get all your users. It's returning a collection, so you need to capture the results in a collection variable. That may be why you had the issue with groups with multiple members.
Query the Group Name to get the distinguishedName
Query on users looking for those who are part of the group, but looking at where the memberOf equals the distinguished name.
What eneded up working was, I just had to change the LDAP Path to stop using the FQDN and instead use LDAP://Company.Local Then it worked like a charm!
The original was like LDAP://Company.Local/OU=Roles,OU=XXX,OU=CLients,DC=Company,DC=Local
While this worked for a group with a single user in it, the query was failing for groups with multiple users.
Changing the LDAP Path to LDAP://Company.Local allowed both single and multi user groups to be queried successfully.