Solved

What are the benefits or pitfalls of having item-level permissions on Nintex 365 Form / WF controlled lists?


Badge +11

In the On-Prem world, with InfoPath forms and standard workflow (SP2010) we designed forms which had their permissions changed soon after creation - so that only certain approving managers could see or access them.

 

Now, we are moving to 365, using Ninex 365 Forms and Workflows on Lists. We have in place solid governance rules in place for our migrations to SharePoint Online, and these cover permissions, and this includes the solutions we build there.

 

I would like, for my solutions, to have the ease-of-design afforded by item-level permissions, as I have on-prem, with permissions changed by workflow (once anyway). But there is push-back against this, on grounds of governance and support.

 

So - what are the pitfalls for item-level permissions?

What are others doing here? Are you controlling this tightly, or is 'the wild west'?

 

I would be grateful for any feedback on this.

icon

Best answer by praios81 15 June 2017, 16:33

View original

2 replies

Userlevel 4
Badge +12

Hello Shaun,

in general I see two pitfalls here - performance and governance.

Performance

Same as in on-prem SharePoint environments custom item permissions generate a huge overhead to the queries to the list, making the list queries slower and slower with each permission given to a single item.

There is a good overview and best practices about single item permissions and performance by Microsoft itself which is also true for Office 365 / SharePoint online: Best practices for using fine-grained permissions in SharePoint Server 2013 

I'd say if you really need to have single item permissions you need an archiving mechanism too. This mechanism will have to delete items or move them from to another, secured, place with inherited permissions but just a few people who can access. Moving the items will assure that you will never have too many items in your original list keeping the platform in good performance but on the same time have all data present if needed.

Governance

This one is especially true if you are giving access to individual people instead of using SharePoint / AD-groups to give access to individual items. Imaging you have 100 items with individual permissions for specific people. One of those people leaves the company and another one takes his/her place. You would have to individually remove all old permissions and give the new permissions to the new person as by default he or she will not see any of the documents because he/she lacks permissions to see the items.

So I'd say if you need to give individual permissions then please do this by using groups whose members you can change centrally, if switching user roles is necessary.

Hope this helps a bit.

Best regards

Enrico

Badge +11

Enrico,

Thank you for these great points.

  • My design generally has the requestor being the only named person with access, all others (whether members of an Approver Group or a System Admin Group) would not be named individuals. So I don't see any issues with losing acces to the items. There may be up to 30-50 people inputting forms to one list, but mostly only a few every day.
  • In my on-prem solutions, I have archived InfoPath forms just to maintain general performance of the working library. But now, in 365, we cannot move the attachments with the list items to another list (we can copy content, but not the attachments). The number of items should not go over thresholds for current solutions, but newer versions for more populus user groups, may push these after a few years' use. Document Generation may give us a way of archiving these, but I'm not convince it is ready for that yet (for forms that may varying numbers and types of attachments , includin non-Office types, such as CAD drawings). It is very important for us to keep the forms and attachments together as one record (which was possible with InfoPath)
  • The lists here would not generally be open to the whole company, so this should reduce some of the query load (I hope); though I understand there may be other indexing crawls that this may affect.

Many thanks, again.

Reply