Applies to:
- Winshuttle Foundation
Winshuttle Composer participant resolver: ADGroup
Participant Resolvers home |
Participant resolvers |
ADGroup |
ADO Net Query |
Custom |
GetFromUserProfile |
LDAP Query |
ODBC Query |
Random from Role |
Select From Role |
SharePoint List Query |
SharePointColumn |
Site Group Driven |
Web Service |
Deprecated |
Dynamic SharePoint List |
Dynamic Web Service |
The ADGroup resolver is similar to the Select From Role resolver, except that it usess an Active Directory Security Group to find assignees instead of a list of assignees assigned to a swim lane in a workflow.
With the ADGroup resolver you can specify an Active Directory Security Group for assignees. Members of the specified group are available to be assigned based on the swim lane Type property.
- Similar to the Select from Role resolver, if Type is set to Person from Role, then a single person can be selected on the form view by the user from the list of the security group’s members.
- If Type is set to Team from Role then the entire list of members of the security group will be assigned.
When to use ADGroup
ADGroup is useful for when you want assignees to be automatically available based on IT management of the user’s Active Directory accounts, .
such as when a new user is hired and IT adds their account to a Master Data Management security group. If ADGroup is used for the swim lane, then the user will automatically be available as a selection on the form without having to adjust and republish the Composer solution.
Active Directory Security Groups are typically only managed by your IT department, so it the downside to using it is that you will likely need to engage your IT department any group membership changes.
If you prefer more direct control over group membership and you are a SharePoint Site Owner for your Form Site, then you can use Select from Role and manually manage your SharePoint group members.
Argument |
Description |
domain |
The name of the specific domain containing the security group within the corporate domain forest. For instance if the group is located in the corp.mycompany.global Fully Qualified Domain Address (FQDN), than the domain value for this parameter should be “corp”, the last portion of the FQDN. |
groupname (required) |
The name of the Active Directory Security Group containing the members to be assigned. |
recursive |
Whether to load users recursively from the group if the group contains other groups. Active Directory Security Groups often contain other Active Directory Security Groups. If the list of assignees needs to contain not only the explicit members of the group, but the members of all nested security groups then this parameter should be set to true. The parameter is set to false by default to reduce performance cost. Recursive listing can tax system resources depending on how many groups are nested within groups. Default value is false. |
display |
For cases where a user will need to select from the list of assignees this parameter should be set to true (the default).
|
allowselect (optional) |
This parameter is a fail over in case no users are found in the target security group.
If this property is set to false and there are no users in the AD group, the process will fail when it reaches an activity in this Swim Lane. |
username (optional) |
In some cases, the Workflow Administrator service account may not be able to read Active Directory and get the security group membership. For example, this might occur if you are targeting a domain that the SharePoint server has not joined. This parameter allows you to specify an account that can read the information and generate a list of assignees. The value should be in the [domain]\[username] format, such as corp\johndoe. If this parameter is not specified, then the Workflow Administrator account will be used. This account can be verified through Workflow Central Administration Farm Configuration page. |
password (optional) |
If the username parameter is used that account’s password needs to be specified in this parameter. |