For anyone working a lot around workflows (via SharePoint Designer, Visual Studio or any of the 3rd party products – such as Nintex) you must have at least once be in the need to add an user to a SharePoint group. This poses 2 challenges at start:
- There is no workflow activity to allow such action – it is almost a no-brainer that breaking inheritance on an item and adding users one-by-one you are pretty soon bound to be confronted with nightmare of managing security. A much better approach is to use SharePoint Groups to add users into those groups, while giving permissions directly to the group on the respective list/library item.
- Permissions one needs in order to execute such activity – but then again, if you would have such activity, and considering that workflows usually run under the credentials of initiator (unless launched specifically under somebody else’s credentials – e.g., via a Web Service call, etc.), you wouldn’t necessarily have the permissions to manage security yourself.
So considering the above what are your options?
Note – For the sake of simplicity, I’ll be exposing a case of achieving this via Nintex in SharePoint 2010 (sorry, I’ve been doing quite a lot of Nintex in past year or so). It is still possible to replicate the functionality pretty easy in other conditions. I would not go through all the steps, as it will be pretty straightforward to create a new workflow with Nintex, be it at the list/library level or site workflows.
Let us consider the 1st point (irrelevant of security yet). The simplest that came to mind was to use of course the SOAP services as these are easily configurable by using a “Call Web Service” activity (you can find the activity in Integration section). Therefore I’ve been:
- Use the UserGroup.asmx standard SharePoint web service (default is under /_vti_bin/UserGroup.asmx). Please note that I’ve made this web relative by using the WebUrl
variable. This will avoid updating it if you plan transferring your workflow further.
- Used the cached credentials (I usually define these are the site collection level in Nintex, via Site Settings > Manage Workflow Constants). Also this would avoid using someone’s credentials and having the workflow failing every time the password expired!
Configured the call to method AddUserToGroup (see more details about its signature http://msdn.microsoft.com/en-us/library/websvcusergroup.usergroup.addusertogroup(v=office.14).aspx). In short the only parameters (as XML elements) important to pass are:
- groupName – this is the actual Name of the group, not the Identifier
- username -the actual account name (domain account) – not here that I’ve used a variable, which I previously collect (it is up to the logic you implemented to ensure populating its value, by example one could use Initiator, or Author, etc.)
- userEmail – though not mandatory, it is recommended as otherwise actual fields which are part of the User Information are not always properly populated.
Figure 1 Add User to group using Web service (Nintex)
Now this would be all – provided that user executing the workflows will always have at least the “Manage permissions” permissions granted, or you are a Site Collection administrator. In all other cases, you would need to use another workaround. What do I mean by “other cases“? Imagine the following (pretty frequently encountered):
Example 1 – You are creating a multi-stage approval workflow, and would like to grant participants permissions on the item as soon as the Approval/Review tasks reach them (not permissions on the Task, but rather on the actual Item on which the Workflow is executing). Of course, those veterans in Nintex will immediately state -that for Approval/Review workflow tasks, Nintex allows to dynamically specify such cases, but this would also hide some business logic, and of course, is not available in all other cases. Let us suppose we want more control, depending on some external conditions. In this case, the above statement just got complicated – you need alternatives.
Example 2 – suppose you are working on building a sort of security matrix (which could contain in a separate column the User/Group to which you need to give permissions) where according to some conditions, you must update security of the current item after evaluating certain rules and identifying which User/Group would need to receive permissions. You want to have permissions automatically updated as soon as the user finished creating/updating the item.
Now, the user which is about to create/update the item (regularly only in need of Contributor permissions) would be confronted with an error as soon as your workflow executes (automatic on item creation/update, or by manual execution).
Reason (and believe me I’ve seen this to be reason for endless hours of debugging – just because most people are not aware of this reality) – the workflow will execute on the context of the Initiator (here being the person updating/creating the item) and of course the method would require him to have “Manage Permissions” rights – which not necessarily can be the case.
In SharePoint Designer 2010, there is the possibility to execute activities by using “Impersonation Step”. Practically, all activities in that “step” would be executed under the permissions of the person who published the workflow.
Figure 2 Add an Impersonation step (SharePoint Designer 2010)
A similar functionality in Nintex is offered by the “Action Set” (with a twist, if I may add) activity is act as a container for grouping multiple activities. In order to use such feature, one needs to go in the Common tab and check the “Run as workflow owner” which simply would simulate the same as with the Impersonation step in the SharePoint Designer 2010. As result, whenever activities contained in the “Action Set” group (aka Child activities) will all execute in the context of the user that published the workflow – in most situations that person is having enough permissions to grant/revoke permissions, update list items, because is been given the “Manage Hierarchy” permissions ahead.
Figure 3 Execute a set of actions in another security context
This is not the entire story, because this action set comes with a set of constraints – you cannot use the “Run as workflow owner” from within an Approval/Review branch or from within activities on the Logic and Flow activities group (e.g. Run If, For-Each, Set a Condition, Run parallel activities, etc. ). Simply, the checkbox won’t be visible.
The result is that you would need to carefully plan your activities ahead in your workflow to ensure that certain conditions are met prior to attempting setting permissions, or updating items in the Initiator’s context. So designing workflows is not only about understanding your business conditions or knowing how to build workflows with your favorite tools, it is also about considering another facet, maybe previously disregarded –the Security impact.
To that end, I found that build state diagrams helped a lot in understanding how various aspect change along the workflow execution flow. Another alternative is getting familiar with BPMN v2 diagrams around Events, Gateways, Activities & Orchestrations and attempt to use it on a regular basis.
Hope it helps,