Yes..you heard correct....
As you might know that for security reasons, a SharePoint designer workflow always runs under the permissions of the user who started the workflow. So how would you perform actions that the workflow initiator does not have access to ? Well, in SharePoint designer 2010 microsoft has introducted a concept called impersonation steps where a sections of the workflow can be run under the identity of the person who authored the workflow rather than by the workflow’s initiator. Thus Impersonating the Steps or actions.
Again, Please note : Impersonation steps run with the permissions of the person who last saved the workflow– typically the workflow template author.
So, When would you impersonate the workflow steps. I have listed some of the scenarios
1. Moving a document from the current library to an archiving library to which the initiator only has read permissions.2. Granting permissions to users – IF in workflow you need to use “Add User to Group” action3. Create a list
What actions can be impersonated – Well here is the list
* Set Content Approval Status (as Owner)
* Create List Item (as Owner)
* Update List Item (as Owner)
* Delete List Item (as Owner)
* Add/Remove/Set/Inherit List Item Permissions (as Owner)
How Do I start with Impersonation – You can create a User-Impersonation Step type step which can then run the sections(under the step) of your workflow under the permissions of the person who authored the workflow. For e.g. In the below steps, if the item is approved, it will be moved to the archive list under authors permissions.
The User-Impersonation type step does have some additional conditions available for efficiently implementing impersonation. Lets look at two major conditions that you would need to implement impersonation -
1. Check list item permissions - The condition simply says the below :
If permissions for these users are at least these permissions on item in this list.
The usage : If permissions for WFApprovers Members are at least Read on item in Current Items
For the above condition to evaluate as true, the users must have at least the permissions that the Read Permission levels provide. This step can very well be used to check that the WFApprovers should have read access to the items.
2. Check list item permission levels - The condition simply says the below :
If permission levels for these users are at least these permission levels on item in this list.
The usage : If permission levels for ikapoor Members are at least Read on item in Current Items.
Please note that : The users can be a single user, multiple users, but you cannot use a group in this condition.
Important Things to remember Notes : Impersonation steps can only be added to the root of a workflow and cannot be nested in another step.
Cheers!!!
As you might know that for security reasons, a SharePoint designer workflow always runs under the permissions of the user who started the workflow. So how would you perform actions that the workflow initiator does not have access to ? Well, in SharePoint designer 2010 microsoft has introducted a concept called impersonation steps where a sections of the workflow can be run under the identity of the person who authored the workflow rather than by the workflow’s initiator. Thus Impersonating the Steps or actions.
Again, Please note : Impersonation steps run with the permissions of the person who last saved the workflow– typically the workflow template author.
So, When would you impersonate the workflow steps. I have listed some of the scenarios
1. Moving a document from the current library to an archiving library to which the initiator only has read permissions.2. Granting permissions to users – IF in workflow you need to use “Add User to Group” action3. Create a list
What actions can be impersonated – Well here is the list
* Set Content Approval Status (as Owner)
* Create List Item (as Owner)
* Update List Item (as Owner)
* Delete List Item (as Owner)
* Add/Remove/Set/Inherit List Item Permissions (as Owner)
How Do I start with Impersonation – You can create a User-Impersonation Step type step which can then run the sections(under the step) of your workflow under the permissions of the person who authored the workflow. For e.g. In the below steps, if the item is approved, it will be moved to the archive list under authors permissions.
The User-Impersonation type step does have some additional conditions available for efficiently implementing impersonation. Lets look at two major conditions that you would need to implement impersonation -
1. Check list item permissions - The condition simply says the below :
If permissions for these users are at least these permissions on item in this list.
The usage : If permissions for WFApprovers Members are at least Read on item in Current Items
For the above condition to evaluate as true, the users must have at least the permissions that the Read Permission levels provide. This step can very well be used to check that the WFApprovers should have read access to the items.
2. Check list item permission levels - The condition simply says the below :
If permission levels for these users are at least these permission levels on item in this list.
The usage : If permission levels for ikapoor Members are at least Read on item in Current Items.
Please note that : The users can be a single user, multiple users, but you cannot use a group in this condition.
Important Things to remember Notes : Impersonation steps can only be added to the root of a workflow and cannot be nested in another step.
Cheers!!!
No comments:
Post a Comment