Welcome to part 8 of the Builder series.
In this video, we’ll add a simple process flow to our app, using Flow Designer.
The concepts introduced here will help you automate your organization’s business processes.
This video builds on the Safety Department use case from previous videos in this series.
We’re logged in to our ServiceNow instance with administrator credentials.
You can also do this with the flow_designer role...
... or delegated_developer role with granted access to Flow Designer.
And again, we’ll start by opening ServiceNow Studio and selecting the Safety application.
Our safety department manager, Luke Wilson...
... wants the safety inspector who’s listed on each Issue record to approve the completed work...
... before closing the issue.
Let’s see how the Now Platform can help us with that.
To create a new flow, we click Create Application File, select Flow Designer…and Flow, and then click Create.
Here, we can choose to create a flow or a subflow.
A subflow is a bit of your process that you may want to use in other process flows.
Unlike flows, subflows lack triggers.
Use a subflow when: You only want to start a flow by calling it from another flow or script.
You want to create a set of reusable operations for use in multiple flows.
You want to specify the inputs available to the subflow when it starts.
You want to specify the outputs available to the parent flow after the subflow ends.
For our Safety app approval, we’ll select flow because it’s a single flow end-to-end,
and we don’t envision anyone needing to trigger this process from another flow or script.
If you’re ever in doubt, you can always create a subflow...
... and then create another flow to trigger it.
Here, we enter a few details about the flow.
We’ll provide a name...
... and validate that we’re in the right scope.
And down here, we have the option to run the flow as the logged-in user or as the system user.
If you run a flow as the system user, it bypasses any security you may have on the records involved.
In some cases, this is what you need because the user who initiated the session...
... may not have permission to modify the data.
In other cases, you’ll want to respect those restrictions.
Consider this choice carefully when creating flows.
But don’t worry – you can always change it later.
For our safety example, we’ll select System User and click Submit to save it.
We’re working in Flow Designer—a Now Platform feature that allows us to use natural language to write process flows.
First, a little orientation.
Across the top, we have tabs for various flows and subflows we might be working on.
In the header are settings and actions for the current flow.
And down the right side is our data panel.
You’ll see how this works as we build out our flow.
The main part of the screen, or canvas, contains two sections: Trigger and Actions.
The trigger specifies the conditions that start the flow.
And the actions are reusable sets of business logic...
... that each produce a specific outcome when provided with its input values.
As a flow runs, actions earlier in the sequence generate outcomes or output values...
... that become available as data to actions later in the flow.
Let’s start by defining the trigger for our example scenario.
We want to run this flow whenever a record is updated on the safety issue table...
... and the State changes to Approval.
And we may need to run the flow more than once, for example, if it’s rejected the first time.
So we’ll set this trigger to run only if it’s not already running.
That’s it for the trigger.
Now, let’s define some actions to carry out if that condition evaluates to true, triggering the flow.
Notice that the Data Panel presents elements we can use from the trigger...
... specifically the issue record...
... the table...
... the fields that changed...
... and when this flow was started.
We call these “data pills,” and we can use them as dynamic inputs to actions that we’ll add in a minute.
Some actions also have outputs, so the data panel will continue to grow...
... and we can use outputs from one action as inputs to a future action.
Let’s begin by adding our first action.
We’ll click the plus sign here and select action...
... and then, under ServiceNow Core, we choose Ask for Approval.
In the form that appears, we can drag the Issue Record data pill to the record field.
We won’t worry about the Approval field and Journal field here...
... because we don’t have them for this type of record.
Next, we’ll define the rules for this approval.
Again, this is very natural.
We want to mark the record as approved or rejected when anyone approves or rejects...
... from the list of people, or single person, we define here.
We could specify individuals or groups….
... or, we could use data from the data panel by opening the issue record...
... and selecting the Inspector field.
Let’s look at another way to get to that field, by using the data pill picker.
Here, we can navigate through the available data panel items in a slightly different way.
In this case, we’ll click Trigger record updated
... and drill into the issue record fields rather than getting the entire record.
We can narrow down the choices by entering the data item we’re looking for here in the search filter.
With a click, the data pill is inserted as the approver.
In no time, you’ll be navigating through the data panel or the data pill picker with ease.
That’s it!
We’re done with the approval activity.
Now we need to specify what to do when the inspector approves or rejects the work.
To do that, we add…
... Flow Logic, and select “if”.
The Condition field should be a clear statement of the condition.
This is helpful for anyone reviewing or maintaining this flow in the future.
For the Condition 1 field, we can either use the data pill picker...
... or just drag the Approval State pill from the data panel.
The available choices appear in the box labeled Select a choice...
... and of course we want to know if it’s approved.
That’s all we’re checking for, so we click Done to close this part of the flow.
Notice now that there’s a fork in the flow.
If our inspector approves the work, the flow proceeds down this right branch.
And when that’s the case, we’ll update the record to indicate it’s closed, complete.
To do that, we add another action, using the smaller plus icon on the branch we want to follow...
... and find the Update Record action.
Once again, we’re going to use the trigger Issue Record…
Here are the fields available to us.
From Add field value, we select State, set the value to Complete, and click Done.
If we wanted to, we could add other actions.
For example, send an email notification to the user in the Opened by field...
... send a Slack message to the Safety technician assigned to the issue, and so forth.
The possibilities are almost limitless.
This is very important: If we were to add more actions after the Update Record...
... we would want to use the Issue record data pill from the output of the Update Record action...
... NOT the trigger record.
The trigger record represents the record when the flow started...
... and doesn’t reflect the changes we just made in the update record changes we just made in the update record.
We want to use the latest applicable record from the data panel as we build our flows.
For now, we’ll just update the record and move on.
To specify what happens if the approval is rejected...
... we add another bit of logic, this time adding an Else condition.
For this branch, we’ll do another record update, setting the state to Work in Progress...
... so that the record goes back into the technician’s queue for followup.
That’s it—We have the basic structure of an approval.
Before deploying this approval flow, we should test it.
Clicking Test bypasses the trigger and allows us to test the logic on any record.
We’ll do that for one of these records.
This link displays the execution details of the flow as it progresses.
It indicates that an approval has been generated for the inspector.
Going to an approval list and checking validates that the approval record is there.
And if this had been in a production instance...
... the inspector would have received an email message with links to approve or reject the work.
Let’s test this by opening the approval record and clicking Approve.
When we refresh the execution details in our flow...
... we see that the inspector approved...
... and the record was updated.
Let’s validate that on the record.
From the Issue list, we see that the State is now Complete.
Our flow is ready to go public.
We close the execution details, close our test dialog box, and click Activate.
A quick confirmation means this flow is actively looking for safety records that meet the trigger condition.
See how easy it is to create flows in Flow Designer to automate your business processes?
Luke, our safety department manager, is loving this way better than the spreadsheet he used to use!
For more information, see our product documentation, knowledge base, or podcast.
Or ask a question in the ServiceNow Community.