extremely useful!

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

Good question Ben. Because the permission level Contribute includes the Edit Item ability, the users are able to edit Web Part pages. See the definition

Edit Items  -  Edit items in lists, edit documents in document libraries, and customize Web Part Pages in document libraries.

It would be nice to be able to separate the ability to edit web part pages but it doesn't appear available. You could edit the Pages library permissions and change the Members group to have read permission as an alternative. Thus restricting the number of editors to the publishing content.

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.

Great insight Rebecca. I would say moving workflows to their own areas is a common design for that purpose. While item creation by impersonation can also solve that problem, it does bring in some risks.

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? ;-)

Thanks Andrew . Actually I gave Read Permission on the Site and struggling since 2 days. After giving Contribute Access the workflow are working fine now. But the problem is user can edit the page which i don't want . I mean why it need contribute access in the Site Level. Does it need any specific list Contribute access (Workflow History) ? Then we can give it manually ?

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).

That's correct. You will also have to provide them contribute to the task list if you use tasks in the workflow. 

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.  

Yes it worked for  me hope will same applied to you.

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.

Hi

I have setup a test for  one of my users for tomorrow morning on  Office 365 intranet site: workflow  + Form 

• Custom list
• A notifiers lookup list
• A settings list
• Workflow Tasks
• Workflow History

Now since locking down permissions two of my workflow instances in my custom list  are now in a suspended state. 

Anyway, I have ensured all the above lists have unique permissions and that all users have at least contribute permissions. I will get one of the managers who submitted a form entry to restart the workflow. I am a bit sceptical that this will fail as I have set web level contribute permissions to general users ( inc my test manager) but will see tomorrow....

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..

I might have been too hasty, as your suggested 'fix'  seems to have worked.  I noticed today the same user who failed to trigger the workflow a week ago,  is now  triggering the same workflow. The only thing that has changed is I have applied unique contribute permissions to all lists involved inc Workflow History and Tasks. Thanks, as I started to compose an apologetic email to one of the managers ;-(

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?

Ryan,

You may well be right. The only thoughts I had was to create a new permission level e.g. Contribute No Edit (SharePoint 2013 Permission levels  .Then ensure all your change actions occur within an Action Set .

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.