Nintex Workflow – Action Set – Part 2 Impersonation
Part 1 of this series was about using Action Sets in Nintex Workflow, and it focused on making your workflows look nicer, so that it’s easier to navigate the workflow and also how you can put actions into an Action Set and then save them as Snippet for later reuse.
Part 2 is about how to use an Action Set to expose one of the ways of impersonation in Nintex Workflow.
When people think about impersonation in SharePoint workflows, it seems to be more about impersonating the person who designed (authored) the workflow. If you have had experience with SharePoint Designer workflows, you’re looking at using the Impersonation Step. Nintex Workflow has similar functionality, but it is built into the Action Set.
Why is Impersonation Needed?
Workflow instances run in the context of the user (initiator) that caused the event that kicked off the workflow.
If a user submits a Leave Request, or an Expense Claim or a company fills in a form to submit a Bid for a Contract, the creation or even modification of those items can cause a workflow instance to start. That instance will run as the user who was logged in to SharePoint that created/modified the item. When the workflow runs, it may need to do certain things that the initiator doesn’t have permissions to do. In that case, you want to look at impersonation. The ability to have some of your workflow logic run as the user who authored the workflow design. In most cases, this is someone who has greater permissions than the average user.
Enabling Impersonation in Nintex Workflow
If you drag an Action Set onto your workflow, and then put in a number of actions into the Action Set, not only is it a nice way to group actions, but it also allows you to have all those actions in the Action Set, run as the owner or author of the workflow.
Open the Action Set configuration and you’ll see a button on the ribbon named “Common”. Click on it.
This will give you a few configurable options, but the one to focus on is the “Run as Owner”. Checking this box will mean that all the actions inside the Action Set will run in the context of the user who designer/authored the workflow design.
Below, you can see a workflow that has an Action Set that we’ve set to Run as Owner.
This user has access to the list we need to query, so the Query List action will work. Also, we’re iterating through the results and creating items in another list, and again, only the owner has access to that list, but regular users do not.
What Other Actions Support Impersonation?
You’ll be interested to know that the Action Set is not the only action that has the option to “Run as Owner”.
- Set a Condition
- State Machine
- Run If
These actions also support impersonation, which makes for some interesting workflow design.
Are there other ways to Impersonate?
Nintex Workflow comes with a web service. Here’s some more info from a colleague of mine (Simon Wright) – http://sharepointed.info/ever-wondered-about-nintex-workflow-web-services/
Part of that web service, is that it exposes two important web methods for impersonation. StartWorkflow, StartWorkflowOnListItem and StartSiteWorkflow. These allow you to start a workflow on an item, document or a Site. The Call Web Service action in Nintex Workflow lets you put n credentials. In effect, you could have a parent workflow start on an event, and then use the Call Web Service action to start a child workflow as a different user. As long as you have their credentials. Most likely in this scenario, you’ll be creating a Nintex Workflow Constant (credential) and use that in the Call Web Service action.
This opens up a whole host of possibilities now, since the workflow isn’t limited to running as a regular user.