Workflow security in Dynamics 365 Finance and Operations
Image by Gerd Altmann from PixabayWhen working with workflow in Microsoft Dynamics 365 Finance and Operations, the users should have proper permissions to be able to not only approve but also submit documents to the workflow. There is no easy guidance on which roles, duties, or privileges to use to ensure having the correct permissions. In case you build up privileges from scratch, you might have questions about how to include the correct permissions for the workflow. In this post, you will learn about the security architecture for workflows and I will share some tips.
Introduction
You might recognize the next scenarios. When you have set up the application and workflow, a user starts complaining that he can’t see the submit button on the documents which he prepared and need to send for approval. Another issue might be an error that a work item can’t be created due to missing security permissions.
With the correct security, you can prevent these security-related errors. Unfortunately, it is not straightforward to know what to add to your security objects. There is no security diagnostics tool for workflow elements in the application. You can try assigning more roles to a user or add standard duties and privileges until you get the desired outcome. However, then there is a high chance that you added too many permissions to a user and you still don’t understand the workflow security architecture.
Workflow security architecture
I will start by explaining that there are some generic and workflow-specific permissions to manage and take care of.
Out of the box, there is some base access to workflow-related functionality included in the System user role. The duty Use basic functionality has a privilege called View workflow history which gives access to the Workflow history page from the main menu and from document forms where workflow is implemented. This privilege also gives access to an action button to Cancel workflows, but without additional permissions for this action on the workflow type, this would not give sufficient permissions to actually stop a workflow instance. A user will only be able to see his own workflow instances. The basic functionality is also added to the security roles Retail store ID and Retail service roles.
The Information technology manager role has a duty that includes a privilege called Maintain workflow instances. When this user or a system administrator opens the Workflow history form, they will see all workflow instances and can check for failed workflows. They can then take additional actions to Resume the workflow after some settings got fixed or Reassign a workflow instance to another user. Like the basic functionality, if a user is not a system administrator, the user would need permission to workflow specific actions.
Next to the common access as mentioned above, there are workflow-specific actions. To know what permissions to grant to users, you would need to understand some technical concepts of workflow development in Dynamics 365 F&O. Don’t worry, I will not start a deep dive into workflow development. I will try to provide just enough information to be able to know what to do for the security permissions. If you don’t have access to a development environment yourself, you can ask a developer to have a look together with you.
You would need to open Visual Studio to get access to the Application Explorer. There is a node called Business Process and Workflow with sub-nodes and all the workflow elements part of the application. Some of these elements contain information about action menu items linked to the workflows. But where to get started?
You would need to start with the Workflow Types, but which one is used for the one we need to find security objects? The application can help you find the correct workflow type. When you set up a workflow, the technical name for the workflow type is in one of the columns.
Now, suppose we want to learn more about the purchase order workflow, we would need to find the Workflow Type PurchTableTemplate in the Application Explorer and open the designer.
When you open a workflow type in the Designer mode, you will be able to see properties in the right window and supported elements in the Designer window.
There are three properties where an action menu item can be linked. As these are menu items, like any other menu item, they will need to be included on a privilege to set the required permissions for users. If a user doesn’t have access to these menu items, the workflow functionality for a workflow type can’t be used correctly. Note that these menu items are targeted, mainly for the workflow submitter. The standard security usually does have these menu items, at least the one for submitting the workflow, part of the maintain privilege for the document, e.g. Maintain purchase orders.
| Cancel Menu Item | Menu item to abort a running workflow instance. |
| Document Menu Item | Menu item to show the form which contains the document which needs to be approved. E.g. the purchase order form. |
| Submit To Workflow Menu Item | Menu item to provide access to the user to be able to start a new workflow instance. |
The supported elements node contain the elements which can be set up in the workflow configuration, like tasks or approval steps. When you select an approval element, in the properties window, the element name is listed. As the property Type is Approval, you can find the element with approval details under the node Workflow Approvals. Open the node and find the value as listed in the property Element name.
On an approval element, there are action menu items linked to different nodes. On the root note of the element, you will find the next properties. The menu items are targeted to an approval user.
| Delegate Menu Item | Menu item to move the approval task to another user. |
| Document Menu Item | Menu item to show the form which contains the document which needs to be approved. E.g. the purchase order form. |
| Resubmit Menu Item | Menu item to provide access to the user to be able to restart a new workflow instance. |
Each outcome element has a property to indicate if it is enabled for the workflow and you can find the Action Menu Item for the outcomes. The screenshot shows the actual menu item which should get the permissions to do the actual approval by a business user.
Find and reuse standard security objects
When you now know to find a list of menu items that should be used to manage permissions for workflow actions, you can choose to either create new privileges or reuse standard objects. I would suggest matching the standard objects if they meet your business requirements. In the Application Explorer, you can find the action menu items in the next path: User Interface > Menu Items > Action. Search for a menu item used in the workflow elements and open it in the designer mode.
When you have the menu item element open, you can use the right mouse to enable a pop-up menu. From this menu choose Addins > View related roles. Then next form will open which gives you insights into all related security objects and in which roles they are used.
In this table, you can view all functional and technical security object names and the permission level for the selected menu item. You can then consider reusing the duty or privilege for your custom role.
There is more…
If you don’t have access to a development environment, you can also consider using the Security configuration form and relying on naming conventions. A majority of the approval workflow privileges start with the word “Approve”. As you can see in the example above, this is not consistent in the application. You can filter all privileges containing the text “Approv” (matches Approve and Approval) and then search for the correct one in the list.
I do hope you liked this post and will add value for you in your daily work as a professional. If you have related questions or feedback, don’t hesitate to use the Comment feature below.
That’s all for now. Till next time!
Original featured image by Gerd Altmann from Pixabay
Image generated by Microsoft Designer
Image by Reimund Bertrams from Pixabay
Image by Gerd Altmann from Pixabay
Hi,
Can you please suggest one of our client in purchase order workflow they are not getting reject button.
Hi Mahaboob,
The reject action is part of the standard privilege Workflow approval tasks for the purchase order header. In case the customer has an own privilege, you can check if the action menu item PurchTableApprovalReject is included and has the correct Grant permissions. If this seems to be OK, there might be another privilege with deny permissions for this menu item.
Good morning Andre. Can there be any restrictions so that standard users and admins cannot resume the workflow?
When you try to recover the flow of an adjustment, it looks like this:
“21/06/2023 10:20:01:
Stopped (unrecoverable): Journal BG Comer, D-01xxx4 is being posted and the workflow status cannot be changed”
Reading the documentation, they suggest that I go to the workflow history and resume the flow. However, the option appears grayed out
Hi Marina,
The error you get and not being able to resume is not related to security as you mentioned that the system administrator is not able to resume the workflow. I would suggest checking if the journal is posted or not. If it is posted, there might be an issue that the workflow got submitted twice by accident.
Dear André, thank you very much for your answer.
Unfortunately the journal is published and the workflow was only submitted once. Should I try to resolve it with a developer? Or do you still consider that there are other alternatives?
Hi Marina,
You can ask a developer to reverse engineer the behavior of the Resume button. What are the conditions to have this field enabled or disabled? Then you would be able to find the root cause. In Feature management, there is also an option to enable “Cancel unrecoverable workflows”. You would be able to cancel the workflow and submit again. (Ensure you test this first in a non-production environment).
thanks! very useful. you are filling a very painful gap in the product documentation with this post.
Hello André – thanks for a great article. You wrote: “The Information technology manager role has a duty that includes a privilege called Maintain workflow instances. When this user or a system administrator opens the Workflow history form, they will see all workflow instances and can check for failed workflows.”.
I would like to grant access for some users to perform actions in the workflow history but am worried about granting them too many rights such as the Information technology manager role. Can I just assign the privilege called Maintain workflow instances to the “Human Resources assistant” role thereby limiting their access to the workflow history only?
Hi Morten,
Thanks for reading this blog and your question. Yes, you can assign the mentioned privilege to another role. That will give visibility to all workflows on the Workflow history form. Depending on the workflow action permissions, they can or cannot recall or resume particular workflows.
Great post Andre. This read was a blessing for the workflow security development. Thank you so much. One quick question. Can we restrict the View history button visibility for some security roles only using X++ code ?
Thanks André,
Have a custom workflow on Sales and users were blocking each other. This post save me a lot of time. Much appreciated.