Flow Designer | Creating Your First Flow

Flow Designer | Creating Your First Flow


This video demonstrates how to create and
test a flow in the Flow Designer. Linked time codes for these topics appear
in the YouTube description for this video. The Flow Designer enables business process owners to create flows using natural language… … to automate approvals, tasks, notifications, and other data in the system… …without having to write code. You build flows using three components: Triggers,
Actions and Flow Logic. The trigger specifies the condition that starts the flow, and can be either a change to a record in the system… …or by a schedule such as daily, weekly, or monthly. The flow runs one or more actions when the
trigger condition occurs. You can control whether or not actions run
by setting up Flow logic… … where you specify the conditions that must be true for them to run. For our example, we want to build a flow for offboarding users that will augment our User Management scoped application. We need it to do two things. First, perform a Lookup for all the user’s
requests in the system, cancel them… … and add a comment to each record that the user is no longer active in the system… …and second, assign all the user’s tasks
to the user’s manager. Let’s create a new flow to provide this functionality. We provide a name that describes exactly what
the flow does. If you need to add more detail, enter a description
as well. For the Application, we select User Management. Here’s an important note. Good design practice is to always put flows within a scoped application… … rather than the global scope, to categorize your content appropriately on the flow canvas… … and to make content easier to maintain and release. When we submit the form, we’re ready to
add the trigger for our flow. We want this flow to be triggered when a user
record is changed from Active to Inactive. So we select Record Updated as the trigger,
then we select the User table. And here we set the condition Active changes from true, meaning that the user record must be inactive to trigger the flow. After the trigger, you can add an action or flow logic. You can see that actions are categorized as core system actions… … global actions, and applications in their corresponding application scopes. The Core System Actions provide generic platform
data handling and tasks. Content in Application Scopes are called Spokes. IT Service Management, Customer Service Management, Security Operations and other products provide spokes for directly manipulating data in those applications. Additionally the IntegrationHub provides integration spokes for taking actions on third party systems like Slack, MS Teams, and HipChat. Now let’s add an action to look up records
to find all the requests made by this user. We want to set a condition that the Requested
for value is this user. We can specify the user record two ways. Either drag the User Record data pill down from the Data panel… … or use the data pill picker to
retrieve the data from the previous step. We can control the maximum number of the results
retrieved in the Max Results field. In this case, the value should be a lot less,
so we leave this as is. And finally, we add an annotation to the action, which is a good idea for making your flows more readable. We’re done adding this action, so let’s
save our work so far. Next, let’s add a flow logic component to
direct what happens next. We need an action performed on records located
by the Look Up… … so we select the For Each option, and drag the Request Records data pill into the Items field. Now let’s add an action. For each Request Record, we want to update the state. So we select Update Record from the ServiceNow
Core actions. We retrieve the records data from the previous step… …and the table is automatically populated. Now we specify the field, or fields, to be updated. First, we select the Request state, and set
the value to Closed Cancelled. Then we select the Additional comments field
and enter the comment to be added to the record… …and click Done. Finally, let’s add an annotation to describe
what this action does. Now we’re ready to add the action to look
up all tasks assigned to this user. So we select the Task table… … and retrieve the user record from the Trigger action. Then we add a flow logic component to apply
an action for each task record. Now we define the action to update each record
to reassign the task to the user’s manager. We access the user record that triggered the
flow to locate the manager field. We annotate the action… …and in just a few minutes, we’ve created our first flow. Now let’s test the flow we just created. Before we get started, here’s an important note. Testing should only be done in a dev or test
instance, not a production instance… … since any record changes caused by the flow or integration calls are real. We select a user to serve as the trigger for the flow. As a test is in progress or after it’s complete… … we can navigate to the Flow Execution view to see the operations details for each action and each action step. The result for each step appears in the State column. And for the flow logic that iterates over several records… … we can view the result for each record and the corresponding details of the actions within them for each item as it relates to that index we chose… … in this case, the second index. For more information, please consult our product
documentation, knowledge base, or podcast. Or ask a question in the ServiceNow Community.


Leave a Reply

Your email address will not be published. Required fields are marked *