Minimum Permissions for Nintex Workflow for Office 365

Hey Andrew,

If we allow people contribute right to the site, that means by default they can edit everything.  e.g. the home page.  Do you have a strategy to allow people to submit forms and run workflows but at the same time not give them access to do things like editing the home page.

Cheers,

Chris

In most (or all) intranets, all users have visitor only rights as you don't want hundreds of people with the ability to edit list items in all lists or edit all pages and documents, delete etc. And it's too impractical and against best practices to break inheritance on all lists/libraries just so users can submit a workflow (e.g. leave request which all users should be able to do without having edit rights).

Our workaround will be moving workflows to a subsite and breaking permissions on that for now.

It may be workwhile Nintex investigating a way around this, e.g. the ability for the workflow to run as the person that published it, so that we don't have to give all users edit rights at site level.

Thanks for the info Andrew.  I'm not the biggest fan of an IA that pushes all workflows/forms to one subsite but it is what it is.  Good old SharePoint huh? ;-)

Hey it work for me I gave Contribute Permission in Workflow History List  ( is a hidden list and you can access it by <site> /lists/Workflow%20History).

Hi Pradipta Nayak‌ are you saying  that if I apply those permissions to <site> /lists/Workflow%20History and workflow tasks I  won't need my users to have site contribute permissions . As mentioned by ‌ , the need to have a sub site just run a workflow seems total overkill.  

And of course, any lists that the workflow will touch (updating items in other lists etc). They must have contribute permissions for this. 

Actually, for our publishing process users create articles in a "drafts" list then the workflow goes through it's approval process and once approved, temporarily gives the user contribute permissions to the LIVE list to create the approved article in the LIVE list and then reverts the user permissions back to read only. This way we can control the publishing process to live without the users being able to sneakily edit a LIVE article.

Update: since adding the above permissions another user has submitted a list item and I can confirm the workflow has suspended.  .  This is a bit of pain as I either relocate list and supporting lookup lists to another location or turn off the workflow all together since all it is really doing is generating a reference and sending a few confirmation emails..

So here's a thought.

I want my users to be able to create an item, but not edit it, however, the workflow will make changes to the item as it progresses. Given that the workflow runs under the identity of the initiator, how can I do this? Or have I just figured out why all the O365 prefixed actions require credentials?

That's exactly what I've done. Created a permission level with just Create items on, assigned the group those permissions for our list and then used the O365 actions to perform the updates on the item that I need to. There are also updates happening on other "hidden lists" so I've left them with contribute privs on those but they don't access those lists themselves, just through the workflow.