Well using "Office 365 update item permissions" action should do the trick. If Requester already has Contribute permissions, why do you want to change them to "Edit"? I don't think I understand the first case.

For the second - simply use the action, indicate the "Manager" as a variable to point to the person selected by the Requester, add this person permissions on the required level (be aware, that Nintex does not support custom permissions' levels) BUT without removing existing permissions and... I think you are home.

The only think that you should remember of is that having "Contribute" permissions on an item does not grant the user permissions to grant permissions to other users. So in that case you should put the action inside the "App Step" action, so that it will be run using elevated permissions.

Regards,

Tomasz

Thank you Tomasz for your reply; let me explain my first case;

"If Requester already has Contribute permissions, why do you want to change them to "Edit"? I don't think I understand the first case."

The requester has Contribute permission, so he can add an item to the list (submit the form). (and he will read ALL the Items submitted by other Users which we don't want !! --> Condition 1 is invalid)

to fix that, I Give the permission: Read/Create items and edit items that were created by the user : so the user can only read/edit the items that he submitted. --> Condition 1 is valid

For the manager : this user Should Read/Edit only the items where he was selected as Manager.

the Action Office 365 update item permission is doing the job, And the manager can read only the Items where he is the Manager. BUT, he can not read them when Condition 1 is valid, i mean when we have the permission Read/Create items and edit items that were created by the user is active. "because the item was not created by the Manager"

so, when we have condition 1 is valid, we lose condition 2 and vice versa !!

I hope i have explained the situation better now;

Any idea how to have condition 1 and 2 both working at same time !!

Please let me know if you have any question.

Thank you for your help;

Regards;

But still, this is easy. I mean - you have to turn off this settings that are limiting access to the list items by the rule of creation, and just handle the permissions using Nintex. So once the item is created you have to use the "Office 365 Update item permissions" action, break inheritance, wipe out existing permissions and then grant them to the author. 

Then, in second action, you should grant permissions to the user who is indicated as a manager. And that's simply it. Both conditions can be met.

Possibly you can even met this two conditions in a single action - just put Author and Manager via variables in action's configuration:

1. Use "ID" selector, to filter and work only on the current file.
2. Break permissions' inheritance
3. Wipe out existing permissions
4. Grant permissions to specific users
5. Add users delimiting them with semicolon. Try to avoid spaces between semicolon and users. I recall it was causing issues some time ago...
6. While adding references to users, use "advanced lookup" to choose "email" or "login" attribute per each user.

7. Choose "Contribute" permissions' level (or other, meeting your requirements):

IMHO that is what you need

Regards,

Tomasz

Thank you Tomasz for your help, what you said is 100% correct if we give contribute permission on site level for a user. then use this O365 action to drop inheritance permission and existing permission on Workflow level.

BUT if i have read Access on Site level permission for a user , and we stop inheritance and give Contribute permission on List level permission for that user, the above config is not working for me ...

the objective is to give only read permission on site level, and Contribute permission on list level (so user can submit the form), then use Office 365 update Item permission Action to give read/write only to the user who create the item.

is that possible ?

Thank you so much for your time;

Well... The same way as I wrote above Read on site level, then broken inheritance on a list level to give users contribute permissions, and then use the action, to alter permissions on a specific item, by removing inheritance and existing permissions and granting new one only on read level...

If, on the other hand, your workflow uses user context to write something, somewhere in the site where you wrote your user has only read permissions, the put all these actions inside the "app step" action to run them with elevated permissions.

 Regards,

 Tomasz

Thank you Tomasz, I did exactly what you said, but i got this error: 

testaccount2 has read permission on site level;

testaccount2 and all users have contribute permission on List level; and inheritance is stopped.

testaccount2 is a member of UAT_Visitors Group;

testaccount2 submits the form;

Part of my Workflow :

with App step or without, same error above;

the User/password has Full Control on site and List level.

this configuration is working fine, if i have contribute permission on site level. once i change it to read permission i got the above error.

please let me know if you have any question or need more details;

Thank you Tomasz.

What message is shown when you open App Step for configuration?

Actions contained within an App Step action inherit elevated permissions.

The required feature is active and App Step is available for use.

Thank you.

Are you sure it is the "set permissions" action that is making the workflow suspended? Not something outside the app step? Can you log before and after?

you are right Tomasz, the workflow suspended before it starts; the user can submit the form and the list has the Item created but the user can not run the workflow;

the workflow is not suspended, the status is started, but seems to be paused.

if i change the user permission on Site level to Contribute, and click "Retry Now" , the workflow run with no issues...

looks like a user with Read permission on site level can not start the workflow,even if he has Contribute permission on the List Level (Reason why the Item is created on the list)

any idea how we can keep Read permission on site level for the user and run the workflow ?

Thank you.

That's easy User must have contribute permissions to the Workflow Tasks and Workflow History lists.  This is a prerequisite for the workflow to run.

 Regards, Tomasz

Correct, i just figure out this and test it, ->  working fine;

Thank you So much Tomasz for your Help;