Skip to main content

I post this, because I couldn't find these information at one place when I needed it, and I think it might be useful for somebody in the future. Please feel free to challenge or extend it. I'm happy to learn more or correct my errors.

We had quite a huge issue with different levels of permissions in different roles, different levels of access to the same data...

Few basics we need to be aware:

  • Workflows will run with the Initiator's permissions, so that the initiator needs Edit rights all through the  life-cycle of the workflow.
  • Initiators usually part of a SharePoint / AD group so they need the same permissions
  • You can set Item level permission in SharePoint but there's no Column level, So if somebody can edit an Item they basically can edit every column in that item.
  • With Nintex workflow you can set up the item level permissions, automate it. (Set Item Permissions)
  • A user who takes part in the workflow need edit rights not just on the Item list, but on the Workflow Taks list too.
  • Only the assignee can edit the Task form.

Different approaches to cover every possible weak-points on List level...

List Form:

  • Create a User Permission level for workflow user in which they have "Contributor" rights without deleting items and create/modify Views rights. So that you can be sure they can't accidentally delete items and they can't access to those columns you don't want (which they can't see through forms).
  • Make the limited view the only public, default view.
  • We Edited the List Form by using IsDislayMode, IsNewMode, IsEditMode properties in Formatting Rules and We put the controls into panels, and assigned the Rules. Hide what you don't want on New Mode, Deny Edit Mode (No controls available).
  • New form had limited available fields, just what's necessary.
  • On the Display Mode form, we used the fn-IsMemberOfGroup("YourSharePointGroupName") function in the Panel/Control's Visibility settings (Visible: Expression)
  • If you're really scared that they still can edit the list's page (webpart settings > Advanced > Target Audiences). Put webparts onto pages with different views.
  • Full control freak: You can edit the List's page, select the list's webpart and set the Target Audience.

Workflow:

  • When the workflow starts you can put a "Set item permission" node in the workflow and remove all the existing rights and create your own.
    • Remove the existing rights
    • Give the Initiator the Contributor like rights (mentioned above)
    • Set the respected groups, people the necessary rights if they need to see (Read) the item all the time)
    • Hint 1: Put a the Site Owner like (Full access) group (which you're part of) to the item with Full access, so later you can still help your users if they make mistakes.
    • Hint 2: sometimes the workflow dies If there's a user task after a Set item permission. Then it's a good solution to put a "wait for 1 minute" action between the two.

182134_pastedImage_21.png

182133_pastedImage_18.png

  • On the Taks nodes (Flexi task, Data request, etc), you can set extra right for the assignee while he/she needs to work on the respecting item/task.
    • You can give the Contributor like rights while she has the task, then you can take it back. Revoke the rights.

182135_pastedImage_24.png

How can I change the permissions based on a managed metadata field? I.e. the Managed Metadata filed = Northern so set the permissions to an 'AD Northern' group or an SharePoint Northern' group.


Does this work with O365?


I am sure I read an article about Microsoft discourage you from using Set Item Permission because it may have an effect on the overall performance as well as is more difficult to have an overview of the overall permissions.

Imagine having 100's of items ... does it not add another 100 separate permissions on top per item?


That's true. But sometimes you can't have the luxury of "nice performance" when business requirements dictate the project priorities happy.png 


Reply