Workflow Automation CoE > Part 2: Designer Access
Goal
In this set of Workflow Automation Center of Excellence articles, you’ll learn about various ways to manage access to the Workflow Automation products Flow Designer, Decision Builder, and Process Automation Designer. This topic is quite complex and covers a range of Platform Capabilities, so I’ll break it up into multiple articles for easier consumption.
- Part 1: Introduction and Application Access
- Part 2: Designer Access (you are here)
- Part 3: Execution Access and Key Takeaways
- (live on Nov 9, 2023) Platform Academy - Securing Workflow Automation Products
Designer Access
The next level of access we’re looking at in this article will be at the designer level. All three designers offer various roles to specify access levels, like read-only roles or granting limited edit access.
Additionally, Flow Designer has two more features: Content Filtering and Feature Access. These can determine which flows, subflows, actions, and triggers can be used by which user roles (e.g., only HR developers may use the HR spokes) or limit access to Flow Designer features like “Save”, “Test”, “Activate”, “Create Code Snippet”, etc.
Roles
Flow Designer
User role access to Flow Designer can be roughly divided into three categories: reading, writing, and reporting.
To give users read-only access to flows, flow actions, and execution details, they can be granted the ‘fd_read’ role. This role includes read-only roles for the individual parts (‘fd_read_flows’, ‘fd_read_actions’, and ‘fd_read_operations’).
For developers to be able to create and modify flows and flow actions, ‘flow_designer’ and ‘action_designer’ are required, respectively. By default, ‘flow_designer’ does not grant access to Action Designer.
Lastly, for access to flow reporting or more detailed access to flow execution details, dashboards, and logs, you can grant ‘flow_report_viewer’ or ‘flow_operator’, depending on the required level of access.
Process Automation Designer
Roles for PAD are tailored to the requirements for authoring processes and the experience configuration.
Granting ‘pd_trigger_author’ allows users to create, update, and delete trigger definitions. The role ‘pd_content_author’ adds permissions to do the same for activity definitions. A full process admin (‘pd_admin’) can do all of the above plus everything included in the ‘pd_author’ role: create, activate, edit, and delete process definitions.
Reporting access to process and activity executions and execution logs is granted through ‘pd_operator’.
Additional roles (‘pd_shared.user’, ‘pd_shared.admin’) allow to view or edit Experience activity types and properties for Playbook Experiences.
Note: Granting access to PAD with these roles does not automatically grant access to Flow Designer. Since process activities run on flows and flow actions, it may also be helpful to assign Flow Designer roles.
Decision Builder
User role access for Decision Builder is built to determine the ability to read, create, edit, or delete specific parts of a decision table.
Read-only access to inputs and decision table rows is granted with ‘decision_table_reader’. Users with this role can also export the decision table to Excel.
The first extension adds edit permissions to the result values for existing decision rows with the ‘decision_result_editor’ role.
The next level of permissions grants access to the entire decision table with the role ‘decision_rule_author’, allowing adding, deleting, and rearranging decision table rows and editing conditions and result values in all rows and columns.
Finally, when you’re either a global admin or granted the ‘decision_table_admin’ role, you can access all parts of Decision Builder and Decision Tables, including inputs, properties, and creating new decision tables.
Flow Designer: Feature Access
Feature Access is a product capability that allows you to restrict access to certain functionality within Flow Designer. For example, you may want to limit access to activating flows, using the try logic, or accessing the error handling section to specific roles.
Feature access is maintained from “Process Automation > Flow Administration > Feature Access List”. This page lists all features that can be restricted from here. There’s also a checkbox that will enable/disable Feature Access Filtering globally.
Required role: ‘admin’
Considerations
Before enabling feature access filtering, take stock of any permissions granted to Flow Designer and Action Designer through roles like ‘flow_designer’, ‘action_designer’, or ‘delegated_developer’. If you don’t add these roles to the features in the list, users with these roles will lose access they currently have once you enable the filtering.
Feature Access Tips
- Anyone with the ‘admin’ role will always have access to all Flow Designer and Action Designer features.
- Add the ‘flow_designer’ role to all features in the flow and subflow authoring categories.
- Add the ‘action_designer’ role to all features in the action authoring category.
- Add the ‘app_template_author’ role to the flow template authoring category if you have activated App Engine Studio and the Flow Template Builder plugins.
- Create or reuse custom roles (and groups) to define feature access classification, e.g.,
- For copying flows, subflows, or flow actions
- For activating flows or publishing subflows and flow actions
- For access to creating code snippets
Flow Designer: Content Filtering
Content Filtering is a product capability that allows you to grant access to certain content within Flow Designer. For example, you may want to limit access to HR-related flow actions or spokes to only be available for HR admins and developers.
Content filtering uses:
- Content definitions to specify types of content.
- Content filtering rules to determine who can access the content.
Flow Designer includes several default definitions and filtering rules. You can set up content filtering by modifying pre-existing rules or creating your own.
Required roles: ‘flow_designer’, ‘action_designer’, or ‘admin’
Note: You will find that the records defined in the Feature Access List (see previous section) will also show up in the filtering rules list.
Considerations
Content filtering rules are additive – different from what you’re used to in ACLs – which means that when you add your own filtering rules to grant access to flow actions in a specific Application scope only for a particular role, you also have to exclude that scope from the default filter rules.
Example
In my example, I created a content definition for all flow actions in the Microsoft Teams Graph Spoke and a rule to apply for the example role ‘filter_2’. Then, I excluded the same app scope from the default filter rule.
Custom Content Definition
Custom Filter Rule
Default Filter Rule
This results in the Spoke Actions no longer showing up for my test user.
Before:
After:
Continue here to read Part 3: Execution Access and Conclusion
