have a look on 'set item permissions' action
I have already tried using it. If I set "read" permission for the Initiator, the workflow fails because there is a state machine that changes states (steps) based on flexi tasks oriented towards approving or sending back the document in different steps. And from what I've read the workflow inherits the permissions of its initiator and when someone approves a task (flexi task in this case) the workflow needs to write that down somewhere deep in the document, thus it needs edit and if the initiator doesn't have it, neither does the workflow so it crashes.
I also tried the options at the bottom of the flexi task (Item Permissions) hoping that they would lock the item for usage just by the designated approvers, also failed.
that's all correct.
but in scenarios like this it is good practice to run workflow with privileges of a dedicated service account (not system account).
so you need to
- design the workflow so that after it is started by an initiator, it impersonates to service account. use 'action set' workflow action and its capability 'run as workflow owner' for that purpose.
if you have simple workflow, you can move all the action into action set. if it is complex one, I would suggest to create small 'starter' workflow with just action set and 'start workflow' actions within action set which would start that complex (main) workflow
- publish (main) workflow from within service account
have a look on following links that discuss the same topic
How to prevent user from editing list item if the workflow is still running?
Thank you VERY much! The action set did the trick! Eliminated the project stopper.
You are awesome!