Applies to:
- Winshuttle Foundation
SharePoint List Query
| 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 |
This resolver allows you to use a SharePoint list to assign tasks to workflow participants using a variety of parameters and/or a logical expression.
This can be useful in scenarios where routing depends on which values a user selects in a form. For example, you could route a form for approval based upon the values selected in one or more fields, such as Manufacturing Plant and Storage Location if a form has a Plant and Storage field values
SharePoint List Query parameters
Argument |
Description |
Required? |
|
allow select |
A Yes/No value that indicates whether to allow the user to select the workflow participants if the query returns nothing. Set to "Yes" this allows the form user to interact with the Pool control within the Process Control element and select or deselect potential participants. When set to "No", the Pool control is not displayed and the form user will be unable to change participants. |
|
|
column |
Name of the column to query. |
Yes |
|
display |
A Yes/No value that indicates whether to display the selected workflow participant. |
No |
|
list |
Name of the list to query. |
Yes |
|
poolcolumn |
Name of the column to query. |
|
|
poollist |
Name of the list to query. |
|
|
poolquery |
Query to run. |
|
|
poolsite |
SharePoint site containing the list you are querying. |
|
|
query |
Query to run. |
Yes |
|
runat |
A Start/End value that indicates when to run the query. |
|
|
site |
SharePoint site containing the list you are querying. |
Yes |
Notes:
The pool options (poolcolumn, poollist, poolquery, poolsite) allow the user to interactively select the participants from the results returned from the query. This Participant resolver can be used in conjunction with the Rerun Pool Query option in the Workflow Participant custom control to allow you to run the Pool Query when the value in a form field changes.
When a query returns a list of users, the task can be assigned to the list of users that match the query, or the task can be reassigned to the list of users who don't match the query. When a poolquery returns a list of users, the task can only be reassigned and only to the list of users who mach the query. To have a reassignment option in the task, the poolquery must be valid and must get the data from the list.
Example
poolsite= http://localhost/grant, poolcolumn=people, poolquery= [division]==@[/my:myFields/my:SPDiv], poollist=Divisions, allowselect=false
Required arguments
The parameters below are the minimum required for the SharePoint List Query resolver.
Site
Enter the URL to the SharePoint site containing the list of approvers.
Example: If your list is at http://mysite/myforms/lists/approvers, then enter http://mysite/myforms.
Tip: You can also copy the URL from your browser by navigating to the site and removing anything after and including the last forward slash (usually /default.aspx or /home.aspx).
Display
Display must be used in conjunction with a Process Control element. When set to "Yes", the participant matched by the query will display within the process control.
List
Enter the name of the list that contains your approvers.
Example: If your list URL is http://mysite/myforms/lists/approvers, then the value for List will be approvers.
Column
This argument indicates which column in your SharePoint list contains the usernames for the approvers. Enter the column name as it appears on the list in the browser.
In the below example, the column name would be the Approver Username column because it contains user names.
Query
The query argument is an expression that filters out the approvers you want to match. Using the expression builder, you can insert fields, promoted values, and/or use logical operators.
For example, if you have a SharePoint list containing approvers for storage areas in plants, it may look something like this:
| Plant | Plant Name | Storage Location | Approver | Approver Username |
| 3105 | Chicago | CH01 | Gerald Kauf | nwh\gkauf |
| 3105 | Chicago | CH02 | Adeline Bhatt | nwh\abhatt |
| 3101 | Des Moines | DM03 | Dan Smithson | nwh\dsmithson |
Query examples
Static Query
You could create a static query (in which the values never change) to always pull Des Moines by entering in the following:
[Plant Name] == "Des Moines"
The [ ] brackets enclose the target SharePoint column name. This statements tells the resolver to find and assign any matches where the Plant Name is equal to the string "Des Moines".
What if you want to target someone based on multiple values, such as Adeline above? You could use this statement:
[Plant Name] == "Chicago" && [Storage Location] == "CH02"
The double ampersand is the logical AND, which means both sides of the expression must match or be true.
Dynamic query
Queries can use dynamic values from the form as well. For example, instead of picking from a long list of approvers, you could have a form that only requires you to enter the storage location and manufacturing plant.
The query expression for this situation would be:
([Plant Name] == @[/my:myFields/my:plant]) && ([Storage Location] == @[/my:myFields/my:storage_location])
This query matches the SharePoint Plant Name column to the value in the form for the "Plant" field. It also matches SharePoint Storage Location column to the "storage_location" field on the form. In this example, you could fill out a form and set the Plant to 3105 and the Storage Location to CH01, and then the form will automatically route to Gerald Kauf.
Important notes
- Use the @ symbol in front of the xpath for fields when building query statements that require a form field value. The @ symbol means that the value should be resolved after the form runs, not before.
- Include each statement in parentheses when you need to compare multiple conditions in a logical statement (as in the example above). This tells the engine to evaluate those conditions in the parentheses first and compare their statement results to the rest.
Pool Arguments
Pool arguments enable you to show matching participants from the resolver to the form user, who can then select from the list.
By using these arguments a special control is created within the Process Control element that shows potential matches on the left, and assignees on the right.
These arguments require the Process Control element to be on the form. When using pool arguments, the equivalent non-pool arguments should be clear.
POOLSITE, POOLLIST, POOLCOLUMN, POOLQUERY
These four arguments are identical to the non-pool arguments described under Required Arguments. Use the same syntax and values.