Workflow Automation CoE > Part 3: Execution 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
- Part 3: Execution Access and Key Takeaways (you are here)
- (live on Nov 9, 2023) Platform Academy - Securing Workflow Automation Products
Execution Access
The final level of access we’ll look at today applies to the actual execution of your workflows and decisions, also referred to as runtime.
First, I’ll give a brief overview of available API functions to run, create, edit, or administer flows, decisions, or processes and their respective executions.
Second, we’ll look at Flow runtime roles, which - by extension - also applies to Process Automation Designer since all process activity definitions have a (sub) flow or flow action to drive them.
Last, we’ll go over a lesser-known feature, which extends the platform feature Restricted Caller Access to flows.
API Access
In this section, we’ll cover some of the more notable and useful APIs for each Workflow Automation product. These can be used from server or client script fields on the Now Platform, depending on which API you’re using.
Flow Designer
The FlowAPI provides methods to execute actions, flows, or subflows in server-side script. The execute functions will run synchronously, the start functions asynchronously. You can also get runners, error messages, stages, outputs, and info on whether a given flow includes approvals. Additionally, you can cancel or restart from a given execution context.
The GlideFlow API enables client-side interactions with actions, flows, or subflows.
Note: The client-side GlideFlow API only works if a given action, flow, or subflow is configured to be client-callable. This setting is available from the top right menu with the option “Manage security”. This will open a new window with a checkbox “Callable by Client API”.
Flow Designer: Quick!
For some of the methods in the FlowAPI, you’ll find a Quick option as well. This method does not create execution details and context records, regardless of Flow Designer settings. It also does not support waiting for conditions like the “Wait for Condition” and “Ask for Approval” actions.
These methods should be used sparingly and only for short, low-complexity flows. One example use case is calling a small subflow or a flow action from a Before Business Rule since triggered flows cannot run in the before context.
Note: If you have been using small if then else flows to make decisions with quick script methods, check out the DecisionTableAPI! It’s a very performant way to create and maintain decisions in a purpose-built way.
Flow Designer: Copy code snippet
This handy feature is available from the menu in the top right of Flow Designer and Action Designer. It opens in a modal with a prepared code snippet to run this flow or action from a server or client script. It contains comments with information about required or optional inputs and outputs and supplies the developer with the option to choose between an asynchronous (background) or synchronous (foreground) execution.
Process Automation Designer
The PDAutomationProvider API inserts an optional activity into a running process execution context.
The PlaybookExperience API provides methods to handle playbook executions. This includes:
- Get a list of playbook executions for a given parent record
- Checking whether a given parent record has playbook executions
- Canceling active playbook executions for a given parent record
- Triggering a new playbook execution for a given parent record
Decision Builder
The DecisionTableAPI class can be used in scoped or global server-side scripts. It provides the developer with various functions to:
- Make a decision based on provided inputs, either the first row that matches with getDecision(String decisionID, Map inputs) OR an array of all rows that match with getDecisions(String decisionID, Map inputs).
- Create, update, or delete different components of a decision table (answer elements, conditions, inputs, etc.)
- Get any components of a decision table (answers, inputs, questions, etc.)
Tip: Check out this article to learn how to leverage the DecisionTableAPI.
Flow Designer: Run as System, Run as User, Run with Roles
In this section, we’ll highlight the option to specify users or roles for a (sub)flow to assume while executing, impacting runtime access to application scopes, records, and fields.
Run as System User
When you run a flow as system, it can perform all actions and access all records except for applications with application-specific admin roles (HRSD is a typical example).
Note: The Flow Designer “Run as system” system user is not a real user in the ‘sys_user’ table and thus has no configuration options.
Run as User
Flows and subflows can be run as the user whose actions triggered the flow (“User who initiates session”). This is the most common setting when building flows with a Service Catalog or Record create/update trigger. This will ensure that a given requestor or agent can only perform actions they are permitted to through their roles and ACLs. If more permissions are required for a given part of the workflow, we recommend breaking that out into a subflow, which will then be run either as system or with additional roles (see next section) as required.
Run with Roles
When a given workflow requires additional permissions beyond those of the user that triggered the flow, these can be added to the flow properties after choosing “User who initiates session”.
Considerations
Flows and subflows each run with their own roles, which means that subflows do not inherit roles from a parent flow. This enables having a flow run in the user context of the user that triggered a record update, then executing certain child logic in a subflow with additional roles or as a system user before returning to the user context in the main flow.
If you want to automate the logic for apps protected by dedicated application-specific admin and developer roles, choose to run the (sub)flow as a specific user that has those roles or as the user that triggered the flow and then add the relevant roles (e.g., ‘hr_admin’) for the flow runtime.
When you test a flow or subflow with the “Test” button in Flow Designer, any “Run As” configuration does not apply. Instead, it’ll run in the system user context.
Lastly, when you run a flow as system, any record updates ('sys_updated_by') will show as 'system' instead of the logged in user that triggered the flow execution.
Note: Even when assigning a role to a (sub)flow, there still may be ACLs blocking access. Review the record ACL rules for that table and fields and grant additional access if your use case requires.
Flow Designer: Restricted Caller Access
Restricted caller access privileges is a Platform feature to restrict and track access to an application, application source, or events. In the Tokyo Release, Flows or Flow Actions have been added as options in the source type choice to track calls to a restricted application, application resource, or event. The HR Service Delivery or Security Incident Response applications are out-of-the-box examples of caller restrictions.
Key Takeaways
Planning
Perform an audit to assess current access levels before implementing new restrictions to ensure a seamless transition to the new process. Establish clear communication and set expectations with all stakeholders and determine authorized approvers for all access levels.
Execution
Be diligent in picking the right features for your requirements. Collaborate with your stakeholders to decide how you want to grant the right access to the right people.
Our recommendation: Create catalog items with fulfillment flows to establish an audit trail. It is considered a good practice on the Now Platform to create user groups from which the group members inherit assigned roles instead of assigning roles directly to a user. Use the catalog item flows to request approval from any authorized person(s) before adding a requestor to an access group.
Note: Learn more about approvals in Flow Designer in this community article: https://sn.works/CoE/FlowApproval
Documentation
Create appropriate documentation about any access restriction definitions and their implementation to avoid confusion down the line. Consider creating dashboards to keep track of access requests and implement processes to regularly audit and review the access restrictions and approval authorization.
Conclusion
Congratulations, you made it through this multi-faceted topic! Application, feature, and execution access are the three main dimensions in which you can grant or deny access for and within the Workflow Automation products.
Since access control is imperative, especially concerning sensitive data and workflows, I hope this article gave you a good overview of different levers to control access in Flow Designer, Process Automation Designer, and Decision Builder.
Center of Excellence Navigation
