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.