Skip to main content

Flow Designer

Detailed Summary of ServiceNow Process Automation Series by Rohit

This series by Rohit is a comprehensive guide to Process Automation in ServiceNow, focusing on Flow Designer and Integration Hub. It's designed for those new to Flow Designer or wanting to deepen their understanding, assuming a basic knowledge of ServiceNow administration and scripting.

Video 1: Introduction to Flow Designer

This video serves as an introduction to the Process Automation series, outlining its scope and the fundamental concepts of Flow Designer. Rohit sets the stage for the series, defining Flow Designer and its intended use cases.

Key points covered:

  • Series Focus: Process Automation in ServiceNow, specifically Flow Designer and Integration Hub.
  • Target Audience: Individuals new to Flow Designer or those with basic knowledge seeking deeper understanding. Assumes prior viewing of Rohit's ServiceNow Admin series and basic scripting knowledge.
  • Scripting Assumption: While minimal scripting is expected, basic scripting understanding is beneficial for certain areas of the series.
  • Definition of Flow Designer: Flow Designer is presented as a graphical representation tool for process owners, emphasizing low-code development and flexibility. It allows for reusable components (actions) across multiple flows, similar to workflows but with enhanced capabilities.
  • Use Cases for Flow Designer: Rohit outlines key areas where Flow Designer is applicable:
    • New Catalog Items: ServiceNow recommends Flow Designer for new catalog items instead of workflows. While workflows are not being deprecated immediately, Flow Designer is the suggested path forward.
    • Automation (Business Rule/Server Script Replacement): Flow Designer can replace server-side scripting like Business Rules and Script Actions, offering a graphical and often code-less approach.
    • Inbound Email Actions: Flow Designer can be used to process inbound emails, similar to traditional inbound email actions.
    • Scheduled Jobs: Flow Designer can automate scheduled tasks, offering an alternative to scheduled script executions.
    • Integration Hub: Flow Designer is tightly integrated with Integration Hub, enabling seamless integration with external applications (e.g., Slack, Zoom, and many others) through pre-built "spokes."
  • Flow Designer Interface Overview: Rohit provides a tour of the Flow Designer interface within a ServiceNow instance:
    • Accessing Flow Designer: Users can search for "Flow Designer" in the left navigation menu (under "Process Automation").
    • Flow Designer UI: Describes the UI as a new page with different tabs:
      • Flows: For creating and managing Flows.
      • Subflows: For creating and managing reusable Subflows.
      • Actions: For creating and managing reusable Actions.
      • Executions: For monitoring Flow executions.
      • Connections: Primarily for Integration Hub connections.
    • Components of a Flow: Explains the three core components of a Flow:
      • Trigger: The event that initiates the Flow (e.g., record creation, catalog item order, inbound email).
      • Actions: Individual steps or tasks performed within the Flow (e.g., create record, send email, ask for approval). Each action performs a specific job.
      • Flow Logic: Conditional logic (e.g., IF/ELSE) that controls the Flow's path based on conditions.
  • Flow Designer Activation: Flow Designer is activated by default in ServiceNow instances. No manual activation is required.
  • Action Execution Limits: Before deploying Flow Designer processes to production, it's crucial to check with your ServiceNow account team regarding action execution quotas and licensing implications.

Video 2: Flow Designer for Catalog Items

This video demonstrates how to use Flow Designer to automate processes triggered by Service Catalog item orders. Rohit outlines a 6-step process for creating a Flow for a simple catalog item.

Key points covered:

  • Scenario: Automating a catalog item order process with manager approval and catalog task generation based on a "Yes/No" variable.
  • 6-Step Process for Catalog Item Flow:
    1. Create a Simple Catalog Item: Rohit fast-forwards through catalog item creation, focusing on a basic item with a single "Manager Approval Request" variable (Yes/No choice).
    2. Attach Flow Designer to the Catalog Item: Shows how to link a Flow Designer flow to a specific catalog item within the catalog item's properties under "Process Engine."
    3. Get Catalog Item Variable: Explains using the "Get Catalog Variables" action in Flow Designer to retrieve the value of the "Manager Approval Request" variable from the ordered catalog item. This involves selecting the "Service Catalog" trigger and the relevant catalog item template.
    4. Generate Conditional Approvals: Demonstrates using "IF" Flow Logic to branch the Flow based on the "Manager Approval Request" variable value (Yes/No).
      • "Yes" Branch: Uses the "Ask for Approval" action to generate manager approval (statically set to "Able Tutor" in the example). Explains selecting the "Requested Item" record and choosing an approval rule ("Anyone Approves").
      • "No" Branch: Uses the "Else" branch of the "IF" condition to bypass manager approval and proceed directly to catalog task creation.
    5. Set Stages: Introduces Flow Stages for visually tracking the progress of the catalog item request.
      • Adding Stages: Shows how to add Flow Stages from the "Flow Stages" option, importing default stages from the "Requested Item" template.
      • Setting Stages within Flow: Explains using the "Set Flow Stage" action to update the RM stage at different points in the Flow (e.g., "Waiting for Approval" before "Ask for Approval", "Fulfillment" before "Create Catalog Task", "Completed" after Catalog Task completion and State update).
    6. Generate Catalog Task and End Flow:
      • "Create Catalog Task" Action: Used in both the "Yes" (after approval) and "No" branches to generate a catalog task. Demonstrates setting task fields like "Short Description," "Assignment Group," and including catalog item variables in the task.
      • "End Flow" Logic: Used to terminate the Flow after Catalog Task creation in both branches and after state update in the rejection path.
    • Rejection Handling: Explains adding an "Update Record" action in the "Else" branch of the "Approval" "IF" condition to set the RM state to "Closed Incomplete" if the manager rejects the approval.
    • Flow Activation and Testing: Shows how to activate the Flow and test it by ordering the catalog item with "Yes" and "No" options. Demonstrates verifying approval generation, catalog task creation, and stage updates based on the selected option.
    • Troubleshooting & Flow Context: Explains how to enable Flow Context logging using the glide.flow.execution.context.persist.level system property to view detailed Flow execution steps and troubleshoot issues. Shows how to access Flow Context from the RM record.

Video 3: Flow as Business Rule (Child Incident Closure)

This video demonstrates how Flow Designer can replace Business Rules, using the example of automatically closing child incidents when a parent incident is resolved.

Key points covered:

  • Scenario: Replicating Business Rule functionality using Flow Designer to close child incidents when the parent incident's state changes to "Resolved."
  • Business Rule Replacement: Highlights Flow Designer as a modern alternative to Business Rules for server-side automation.
  • Flow Trigger (Record Update): Sets up the Flow trigger to be "Record Updated" on the "Incident" table.
    • Trigger Condition: Specifies the condition: "State changes to Resolved."
  • Lookup Records Action (Child Incidents): Uses the "Lookup Records" action to find all child incidents related to the parent incident being resolved.
    • Table: "Incident" table.
    • Filter: "Parent incident is [Trigger Record - Incident Record]." This dynamically filters for incidents where the "Parent incident" field matches the current incident triggering the Flow.
  • For Each Loop (Iterate through Child Incidents): Employs the "For Each Record" Flow Logic to loop through each child incident found by the "Lookup Records" action.
    • Records: Selects "Lookup Records - Incident Records" as the records to iterate over.
  • Update Record Action (Close Child Incidents): Inside the "For Each Loop," uses the "Update Record" action to close each child incident.
    • Record: Selects "For Each - Incident Record" (the current child incident in the loop).
    • Fields to Update: Sets the "State" to "Resolved," "Resolution code" (mapped from parent incident), and "Resolution notes" (mapped from parent incident). Demonstrates mapping "Resolution code" and "Resolution notes" from the "Trigger Record - Incident Record" (parent incident) to ensure consistency.
  • Flow Activation and Testing: Shows how to activate the Flow and test it by resolving a parent incident with child incidents. Verifies that child incidents are automatically resolved and resolution details are copied from the parent.
  • Code-less Implementation: Emphasizes that the entire Business Rule logic is implemented in Flow Designer without writing any scripting code.

Video 4: Flow as Workflow Replacement (Problem Management)

This video illustrates how Flow Designer can replace traditional Workflows, using a Problem Management process as an example. Rohit recreates a simplified Problem Management workflow in Flow Designer.

Key points covered:

  • Workflow Replacement: Reinforces Flow Designer as the recommended alternative to Workflows for new automation processes.
  • Problem Management Workflow Scenario: Outlines a simplified Problem Management process:
    1. Problem Creation ("New" State).
    2. Problem Assessment ("Assess" State) -> Manager Approval.
    3. Root Cause Analysis ("Root Cause Analysis" State).
    4. Fix in Progress ("Fix in Progress" State).
    5. Problem Resolution ("Resolved" State) -> Incident Closure & Notification.
  • Flow Trigger (Record Update - Assess State): Sets the Flow trigger to "Record Updated" on the "Problem" table, firing when the Problem state is changed to "Assess."
    • Trigger Condition: "State is Assess."
  • Ask for Approval Action (Manager Approval): Generates a manager approval when the Problem enters the "Assess" state.
    • Record: "Trigger Record - Problem Record."
    • Approver: Dynamically sets the approver to the "Assign to" user of the Problem record.
  • IF Flow Logic (Approval/Rejection Branching): Creates an "IF" condition to handle approval and rejection scenarios.
    • "Approved" Branch:
      • Update Record Action (Root Cause Analysis State): Moves the Problem state to "Root Cause Analysis."
      • Wait for Condition Action (Resolved State): Holds the Flow execution until the Problem state is manually changed to "Resolved."
      • Lookup Record Action (Incident Closure): Finds the "First reported by" Incident record associated with the Problem.
      • Update Record Action (Incident Resolution): Resolves the Incident record, setting "Resolution code" and "Resolution notes" (mapped from the Problem record).
      • Send Email Action (Incident Resolution Notification): Sends an email notification to the Incident caller, informing them of the Problem resolution and the associated Incident closure. Uses Transform Functions for formatting the email body (getting first name, capitalizing it, and formatting dates).
    • "Rejected" Branch (Else):
      • Update Record Action (New State): Moves the Problem state back to "New."
      • Update Record Action (Work Notes): Adds a work note to the Problem record indicating rejection.
  • Wait for Condition Action (Resolved State): Used to pause the Flow until the Problem reaches the "Resolved" state (manual step after "Fix in Progress").
  • Resolve Incident Sub-Process: Includes actions to resolve the associated Incident after the Problem is resolved (Lookup Record and Update Record).
  • Email Notification: Sends an email to the Incident caller upon Problem resolution.
  • Flow Activation and Testing: Shows how to activate the Flow and test it by creating a Problem, moving it through the states, and verifying approval generation, state transitions, Incident resolution, and email notification.
  • Transform Functions for Email: Demonstrates using Transform Functions for formatting the email content: capitalizing the first name of the requested by user and formatting dates.

Video 5: Trigger Flow from Inbound Email

This video demonstrates triggering Flow Designer flows based on inbound emails, offering an alternative to traditional Inbound Email Actions.

Key points covered:

  • Inbound Email Flow Trigger: Explains how to configure a Flow Designer flow to be triggered by incoming emails to ServiceNow.
  • Inbound Email Trigger vs. Inbound Actions: Highlights the benefits of using Flow Designer for inbound email processing, including greater flexibility and code-less automation capabilities compared to traditional Inbound Actions.
  • Flow Trigger (Inbound Email): Sets the Flow trigger to "Inbound Email."
    • Trigger Condition: Specifies the condition: "Subject starts with Create incident." This means the Flow will be triggered for emails with subjects beginning with "Create incident."
  • Create Record Action (Incident Creation): Creates an Incident record upon receiving a matching email.
    • Table: "Incident" table.
    • Field Mappings: Maps email data to Incident fields:
      • Short Description: Mapped from "Trigger - Email Record - Subject."
      • Description: Mapped from "Trigger - Email Record - Body text."
      • Caller: Statically set to "Able Tutor" (for demonstration; in real-world scenarios, you would dynamically determine the caller based on email sender).
  • Lookup Records Action (Email Attachments): Finds attachments associated with the inbound email.
    • Table: "sys_attachment" table.
    • Filter: "Table sys_id is [Trigger - Inbound Email Record - sys_id]." This finds attachments linked to the current inbound email record.
  • For Each Loop (Copy Attachments): Iterates through each attachment found by the "Lookup Records" action.
    • Records: "Lookup Records - Attachment records."
  • Copy Attachment Action (Copy to Incident): Copies each email attachment to the newly created Incident record.
    • Attachment record: "For Each - Attachment record."
    • Target record: "Create Record - Incident Record."
  • Flow Activation and Testing: Shows how to activate the Flow and test it by simulating an inbound email.
    • Testing Method: Due to PDI environment limitations, Rohit demonstrates creating a new record directly in the c_email table (ServiceNow's email log table) to simulate an inbound email. This involves setting the Subject, Body, and Content Type to mimic a real email.
    • Reprocessing Email: Explains using the "Reprocess Email" UI Action on the c_email record to trigger the Flow based on the simulated email.
    • Verification: Verifies that an Incident is created with the correct Short Description, Description, and attached files from the simulated email.
  • Email Log Table (c_email): Mentions the c_email table where ServiceNow stores both incoming and outgoing emails.

Video 6: Subflows

This video focuses on Subflows in Flow Designer, explaining their purpose and demonstrating their creation and usage.

Key points covered:

  • Subflow Definition: Subflows are defined as reusable sequences of actions designed to be called from Flows or other Subflows. They promote modularity and reusability in automation processes.
  • Use Cases for Subflows: Subflows are ideal for encapsulating common or standardized processes, such as:
    • Creating Change Requests
    • Creating Incidents
    • Sending Notifications
    • Integration Steps
  • Creating a Subflow - "Create Change Request": Provides a step-by-step guide to create a Subflow named "Create Change Request."
    • Subflow Properties: Shows how to set the Subflow name.
    • Input Parameters: Explains creating Input Parameters for a Subflow to receive data when called. In this example, three Input Parameters are created: "Short Description" (String, Mandatory), "Description" (String, Mandatory), and "Assignment Group" (Reference, Optional).
    • Create Emergency Change Action: Uses the "Create Emergency Change Request" action from the ITSM spoke to create a Change Request. Maps the "Short Description" and "Description" Input Parameters to the corresponding Change Request fields.
    • Update Record Action (Assignment Group): Updates the newly created Change Request to set the "Assignment Group" field, mapping it to the "Assignment Group" Input Parameter.
    • Output Parameter (Change Number): Explains creating an Output Parameter named "Change Request" (Reference to Change Request table) to return the sys_id of the created Change Request.
    • Assign Subflow Output Action: Uses the "Assign Subflow Output" action to set the value of the "Change Request" Output Parameter to the sys_id of the Change Request created in the "Create Emergency Change Request" action.
  • Subflow Testing: Demonstrates testing the Subflow directly using the "Test" button. Shows how to provide test input values for the Input Parameters and verify the Subflow execution and output.
  • Calling Subflow from a Flow: Explains how to call the "Create Change Request" Subflow from a Flow.
    • Flow - "Incident Resolved by Change" (Modified): Modifies the existing "Incident Resolved by Change" Flow from Video 4.
    • Subflow Action: Adds a "Subflow" action to the Flow.
    • Selecting Subflow: Shows how to search for and select the "Create Change Request" Subflow.
    • Input Parameter Mapping: Explains how to map Flow data (e.g., Incident Short Description, Resolution Notes, Assignment Group) to the Input Parameters of the called Subflow.
    • Update Record Action (Incident - Change Request Field): Adds an "Update Record" action to the Flow to update the Incident record with the "Change Request" number returned as the Output Parameter from the Subflow.

Video 7: Calling Subflows from UI Actions

This video demonstrates how to call Subflows directly from UI Actions, enabling users to trigger complex automated processes from button clicks or context menu options.

Key points covered:

  • Calling Subflows from UI Actions: Explains how to trigger Subflows from UI Actions, providing a user-initiated way to execute automated processes.
  • Code Snippet for Subflow Calls: Shows how to generate code snippets for calling Subflows from scripts within Flow Designer. Accessing the "Create code snippet" option from the Subflow menu.
  • Server-Side Script Snippet: Focuses on the Server-side code snippet for UI Action usage. Explains the structure of the code snippet, including:
    • Input Parameter Passing: How to pass values to the Subflow's Input Parameters using a inputs object.
    • Subflow Execution: How to execute the Subflow using sn_fd.FlowAPI.getRunner().subflow(subflowSysId).inBackground().withInputs(inputs).run().
    • Output Retrieval (Example): How to access the Output Parameters returned by the Subflow.
  • Creating a UI Action - "Create Change Request": Provides a step-by-step guide to create a UI Action on the "Problem" table to call the "Create Change Request" Subflow.
    • UI Action Properties: Sets the Table to "Problem," UI Action Name to "Create Change Request," and sets it as a "Form Button."
    • Server-Side Script (UI Action Script): Pastes the Server-side code snippet into the UI Action's "Script" field.
    • Parameter Mapping (UI Action Script): Modifies the code snippet to dynamically pass Problem record data to the Subflow Input Parameters:
      • Short Description: current.short_description
      • Description: current.description
      • Assignment Group: current.assignment_group (initially disabled in the example, later re-enabled with a note about needing to handle GlideRecord object).
    • Output Handling (UI Action Script): Modifies the code snippet to retrieve the "Change Request" Output Parameter from the Subflow and update the Problem record's "Close notes" field with the Change Request number.
    • current.update(): Includes current.update() to save the changes made to the Problem record (updating the "Close notes" field).
  • Testing the UI Action: Demonstrates testing the UI Action by clicking the "Create Change Request" button on a Problem record and verifying that the Subflow executes, a Change Request is created, and the Change Request number is displayed in the Problem's "Close notes" field.
  • Error Handling (Try/Catch): Notes the inclusion of a try...catch block in the code snippet for basic error handling.
  • Client-Side Code Snippet: Briefly mentions the availability of a Client-side code snippet but notes that Subflow client-side calls might have limitations.

Video 8: Transform Functions

This video focuses on Transform Functions in Flow Designer, highlighting their no-code approach to data manipulation.

Key points covered:

  • Transform Function Definition: Transform Functions are defined as built-in, no-code functions within Flow Designer that allow users to manipulate data (strings, dates, numbers) without writing scripts.
  • Use Case: Change Request Scheduled State Automation: Presents a scenario where Transform Functions are used in a Flow to automate tasks when a Change Request moves to the "Scheduled" state:
    • Set Planned End Date: Automatically calculate and set the "Planned end date" to be 5 days after the "Planned start date."
    • Send Email Notification: Send an email notification when the Change Request reaches the "Implementation" state, including formatted dates and capitalized user names.
  • Flow Trigger (Record Update - Scheduled State): Sets the Flow trigger to "Record Updated" on the "Change Request" table, firing when the Change Request state is changed to "Scheduled."
    • Trigger Condition: "State changes to Scheduled."
  • Update Record Action (Set Planned End Date): Updates the Change Request record to set the "Planned end date."
    • Field: "Planned end date."
    • Value (Transform Function - Add Time): Demonstrates using the "Add Time" Transform Function to calculate the "Planned end date."
      • Input Value: "Trigger Record - Change Request - Planned start date."
      • Function: "Date and Time - Add Time."
      • Time to Add: "5 Days."
  • Wait for Condition Action (Implementation State): Pauses the Flow until the Change Request state is manually changed to "Implementation."
    • Condition: "State is Implementation."
  • Send Email Action (Implementation Notification): Sends an email notification upon reaching the "Implementation" state.
    • Recipient: "Trigger Record - Change Request - Requested by."
    • Subject: "Trigger Record - Change Request - Short description" + "Trigger Record - Change Request - Planned start date."
    • Body (Transform Functions - String Split, Get Array Item, To Upper Case, Date to String): Demonstrates using a combination of Transform Functions to format the email body:
      • Get First Name (Capitalized):
        • String Split: Splits the "Trigger Record - Change Request - Requested by - Name" (full name) string by spaces to create an array of names.
        • Get Array Item: Extracts the first item (first name) from the name array.
        • To Upper Case: Converts the extracted first name to uppercase.
      • Format Dates (Planned Start Date, Planned End Date):
        • Date to String: Uses the "Date to String" Transform Function to format the "Trigger Record - Change Request - Planned start date" and "Trigger Record - Change Request - Planned end date" into a specific "Day, Month Date, Year" format.
  • Testing Transform Functions: Shows how to test Transform Functions directly within the Flow Designer by clicking the "FX" icon next to data pills and using the "Test" button.
  • Exploring Transform Function Categories: Mentions different categories of Transform Functions available: Math, Date and Time, String Utils, Sanitize, etc., encouraging users to explore them.

Video 9: Inline Scripting

This video focuses on Inline Scripting in Flow Designer, addressing when and how to use scripting within a low-code environment.

Key points covered:

  • Inline Scripting in Flow Designer: Explains that while Flow Designer aims for low-code automation, Inline Scripting is available for situations where complex logic is needed that cannot be achieved using out-of-box actions or Transform Functions.
  • Considerations Before Using Inline Scripting: Emphasizes important considerations before resorting to Inline Scripting:
    • Use for Small, Non-Reusable Logic: Inline Scripting is best suited for short, specific pieces of code that are not intended for reuse in other Flows or Actions.
    • Check for Transform Functions: Always explore Transform Functions first to see if they can achieve the desired data manipulation without scripting.
    • Consider Custom Actions/Subflows for Reusability: If the logic is more complex or reusable, consider creating Custom Actions or Subflows instead of using Inline Scripting directly within a Flow.
  • Use Case: Subflow Update - Short Description Character Limit: Presents a scenario to update the "Create Change Request" Subflow to limit the Change Request Short Description to 15 characters, appending "..." if it exceeds the limit.
  • Modifying "Create Change Request" Subflow:
    • Flow Variable - "Short Description": Creates a Flow Variable named "Short Description" (String type) within the Subflow.
    • Set Flow Variables Action (Initial Variable Value): Adds a "Set Flow Variables" action to assign the value of the "Short Description" Input Parameter to the newly created "Short Description" Flow Variable.
    • Update Record Action (Change Short Description - Inline Script): Modifies the "Update Record" action in the Subflow to set the Change Request "Short Description" using Inline Scripting.
      • Field: "Short Description."
      • Value (Inline Script): Demonstrates using Inline Scripting to implement the character limit logic.
        • Variable Declaration: var v_short_description = FDData.flowVariables.short_description; Retrieves the value of the "Short Description" Flow Variable.
        • Length Check (IF Condition): if (v_short_description.length > 15): Checks if the length of the Short Description exceeds 15 characters.
        • Substring and Concatenation (THEN Branch): return v_short_description.substring(0, 15) + '...';: If the length exceeds 15, it extracts the first 15 characters using substring() and appends "..."
        • Return Original Value (ELSE Branch): else { return v_short_description; }: If the length is 15 or less, it returns the original Short Description value.
  • Testing Inline Scripting: Shows how to test the Subflow with different Short Description inputs (short and long) and verify that the Inline Script correctly limits the character length and appends "...".
  • Show Related Flows Option: Demonstrates the "Show related flows" option in the Subflow menu, allowing users to see which Flows are using a particular Subflow.

Video 10: Parallel and Do-Until Flow Logic

This video covers two important Flow Logic actions: "Do Following Parallel" for parallel task execution and "Do Until" for creating loops based on conditions.

Key points covered:

  • Parallel Flow Logic ("Do Following Parallel"): Explains how "Do Following Parallel" Flow Logic allows multiple actions to execute concurrently in separate branches.
  • Do Until Flow Logic: Explains how "Do Until" Flow Logic creates loops that repeat actions until a specified condition is met.
  • Use Case: Asset Request Catalog Item with Parallel Tasks and Asset Creation Loop: Demonstrates a scenario for an "Asset Request" Catalog Item that involves:
    • Manager Approval.
    • Parallel Catalog Tasks (Hardware and Software Teams).
    • Asset Creation Loop (based on Requested Asset Count).
  • Creating a Catalog Item Flow - "Asset Requested" (Modified): Modifies the existing "Asset Request" Catalog Item Flow to incorporate Parallel Tasks and the Asset Creation Loop.
  • Flow Stages: Adds Flow Stages ("Waiting for Approval," "Fulfillment") to track the request progress.
  • Manager Approval Action: Keeps the Manager Approval action from previous videos.
  • Do Following Parallel Flow Logic (Parallel Catalog Tasks): Adds "Do Following Parallel" Flow Logic to create two branches for parallel Catalog Tasks.
    • Branch 1 (Hardware Catalog Task): Creates a Catalog Task for the "Hardware" team with a specific Short Description, Assignment Group ("Hardware"), and including catalog item variables.
    • Branch 2 (Software Catalog Task): Creates a Catalog Task for the "Software" team, similar to the Hardware task but with different Short Description and Assignment Group ("Software").
  • Flow Variable - "Asset Count" (Integer): Creates a Flow Variable named "Asset Count" of Integer type, initialized to 0.
  • Set Flow Variables Action (Initialize Asset Count): Adds a "Set Flow Variables" action to initialize the "Asset Count" variable to 0 before the loop.
  • Do Until Flow Logic (Asset Creation Loop): Adds "Do Until" Flow Logic to create a loop that repeats until the desired number of assets are created.
    • Condition: "Flow Variables - Asset Count is less than [Get Catalog Variables - Asset Requested (converted to Number using String to Number Transform Function)]." This condition checks if the current "Asset Count" is less than the "Asset Requested" value from the Catalog Item. Uses the "String to Number" Transform Function to convert the Catalog Item variable (which is initially a String) to an Integer for numerical comparison.
    • Loop Actions:
      • Set Flow Variables Action (Increment Asset Count): Increments the "Asset Count" variable by 1 in each loop iteration using the "Math - Add" Transform Function.
      • Create Record Action (Hardware Asset Creation): Creates a new "Hardware Asset" record in each loop iteration. Sets mandatory fields like "Model category," "Model," and "Asset tag" (setting "Asset tag" to the current "Asset Count" Flow Variable for tracking purposes).
  • Testing Parallel Tasks and Do Until Loop: Demonstrates testing the Flow by ordering the "Asset Request" Catalog Item and verifying:
    • Manager Approval Generation.
    • Parallel Catalog Task Creation (Hardware and Software).
    • Do Until Loop Execution: Verifies that the "Do Until" loop runs the correct number of times (based on the "Asset Requested" value) and creates the corresponding number of Asset records.
  • Diagram View: Shows the Diagram View of the Flow Designer, providing a visual representation of the Flow logic, including Parallel Branches and the Do Until Loop.
  • Correcting Loop Condition: Corrects a mistake in the initial loop condition (using "less than" instead of "greater than" for the "Until" condition), highlighting the importance of accurate condition logic.

Video 11: Decision Builder

This video introduces Decision Builder (Decision Tables) in Flow Designer, demonstrating how to create rule-based decision logic without complex IF/ELSE structures.

Key points covered:

  • Decision Builder Definition: Decision Builder (Decision Tables) is defined as a tool for creating rule-based decision logic in a tabular format. It simplifies complex conditional logic and makes it easier to manage and update decision rules.
  • Use Case: Asset Approval Routing based on Asset Type and Manufacturer: Presents a scenario for routing asset approvals to different groups based on a combination of "Asset Type" (Laptop, Desktop) and "Manufacturer" (Apple, HP).
  • Creating a Decision Table - "Asset Result": Provides a step-by-step guide to create a Decision Table named "Asset Result."
    • Navigating to Decision Builder: Accessing the "Decision Builder" module under "Decision Management."
    • Creating New Decision Table: Clicking "Create new Decision Table."
    • Table Name: Setting the Decision Table name to "Asset Result."
    • Input Columns: Defining Input Columns (Conditions) for the Decision Table:
      • Asset Type: Choice List type with choices "Laptop" and "Desktop."
      • Manufacturer: Choice List type with choices "Apple" and "HP."
    • Result Column: Defining the Result Column (Output) of the Decision Table:
      • Approval Group: Reference type to "sys_user_group" table.
    • Adding Decision Table Rules: Demonstrates adding rules to the Decision Table to define the output (Approval Group) based on different combinations of Input values (Asset Type and Manufacturer):
      • Rule 1: Laptop, Apple -> Hardware Group
      • Rule 2: Desktop, Apple -> Hardware Group
      • Rule 3: Laptop, HP -> Hardware Group
      • Rule 4: Desktop, HP -> CAB Approval Group
  • Integrating Decision Table into Flow - "Asset Request" (Modified): Modifies the "Asset Request" Catalog Item Flow to use the "Asset Result" Decision Table for dynamic Approval Group assignment.
  • Make Decision Flow Logic Action: Adds the "Make Decision" Flow Logic action to the Flow.
    • Decision Table: Selects the "Asset Result" Decision Table.
    • Input Mappings: Maps Catalog Item Variables ("Asset Type," "Manufacturer") to the Input Columns of the Decision Table.
  • Ask for Approval Action (Group Approval - Dynamic Group): Modifies the "Ask for Approval" action to use Group Approval and dynamically set the Approval Group based on the Decision Table result.
    • Approvers: Sets the Approvers to "Make Decision - Asset Result - Result - Approval group." This dynamically pulls the Approval Group from the Decision Table's output.
  • Flow Activation and Testing: Shows how to activate the Flow and test it by ordering the "Asset Request" Catalog Item with different combinations of Asset Type and Manufacturer, verifying that the correct Approval Groups are dynamically assigned based on the Decision Table rules.
  • Benefits of Decision Builder: Highlights the advantages of using Decision Builder:
    • Simplified Complex Logic: Makes complex conditional logic easier to manage in a tabular format.
    • Improved Maintainability: Decision rules are stored in a separate Decision Table, making updates and modifications easier without altering the Flow logic itself.
    • No-Code Rule Management: Business users can potentially manage and update decision rules directly in the Decision Table without requiring Flow Designer modifications.

Video 12: Dynamic Flow Logic

This video explores Dynamic Flow Logic in Flow Designer, enabling runtime selection of Flows or Subflows based on dynamic conditions.

Key points covered:

  • Dynamic Flow Logic Definition: Dynamic Flow Logic allows Flows to dynamically call different Subflows or Flows at runtime, based on conditions or data available during Flow execution. This provides greater flexibility and adaptability compared to statically calling Subflows within a Flow.
  • Use Case: Dynamic Subflow Call based on Manufacturer: Demonstrates a scenario where different Subflows are called based on the "Manufacturer" selected in the "Asset Request" Catalog Item.
  • Template Subflow - "Template: Asset Requested": Creates a Template Subflow named "Template: Asset Requested" that serves as the base template for specific Subflows.
    • Input Parameter: Includes an Input Parameter "Asset Required" (Integer type).
    • Action (Log - Placeholder): Includes a placeholder Log action within the Template Subflow (for demonstration purposes).
  • Specific Subflows - "Template: Asset Requested - Apple" and "Template: Asset Requested - HP": Creates two specific Subflows: "Template: Asset Requested - Apple" and "Template: Asset Requested - HP," by copying the Template Subflow.
    • Similar Input Parameters: These specific Subflows have the same Input Parameters as the Template Subflow ("Asset Required").
    • Different Actions (Log - Placeholder): These specific Subflows could contain different actions relevant to each manufacturer (e.g., different integration steps, notifications). In the example, they contain placeholder Log actions.
  • Modifying Main Flow - "Asset Request" (Dynamic Flow Logic): Modifies the "Asset Request" Catalog Item Flow to use Dynamic Flow Logic to call the specific Subflows based on the "Manufacturer" selection.
  • Dynamic Flow Logic Action: Adds the "Dynamic Flow" Flow Logic action to the Flow.
    • Template Flow: Selects the "Template: Asset Requested" Template Subflow.
    • Flow Name String: Defines a string that dynamically constructs the name of the Subflow to be called at runtime. The string is constructed as: "Template: Asset Requested - " + [Get Catalog Variables - Manufacturer]. This dynamically appends the selected Manufacturer value (Apple or HP) to the base Template Subflow name.
    • Input Mapping: Maps the "Asset Requested" Catalog Item Variable to the "Asset Required" Input Parameter of the Dynamic Subflow.
  • Wait for Completion Action: Adds a "Wait for Completion" action after the Dynamic Flow Logic to ensure the main Flow waits for the dynamically called Subflow to complete before proceeding.
  • Testing Dynamic Flow Logic: Demonstrates testing the Flow by ordering the "Asset Request" Catalog Item with different Manufacturers (Apple and HP), verifying that the correct specific Subflow ("Template: Asset Requested - Apple" or "Template: Asset Requested - HP") is dynamically called based on the Manufacturer selection.
  • Benefits of Dynamic Flow Logic: Highlights the advantages of Dynamic Flow Logic:
    • Flexibility and Adaptability: Allows Flows to dynamically adapt their behavior at runtime based on data or conditions.
    • Simplified Complex Flows: Reduces the need for long and complex IF/ELSE chains by dynamically selecting different Subflows for different scenarios.
    • Improved Maintainability: Makes it easier to manage and extend automation processes with many variations by separating specific logic into individual Subflows that are dynamically called.

Video 13: Out-of-Box Actions

This video provides a summary of key out-of-box Actions available in Flow Designer, emphasizing their reusability and functionality.

Key points covered:

  • Out-of-Box Flow Designer Actions: Provides an overview of commonly used and important out-of-box Actions available in Flow Designer, highlighting their capabilities.
  • List of Key Out-of-Box Actions (and brief descriptions):
    • Ask for Approval: Generates user or group approvals for records.
    • Create Record / Update Record: Creates new records or updates existing records in ServiceNow tables.
    • Lookup Record / Lookup Records: Queries ServiceNow tables to find single or multiple records based on specified criteria.
    • Delete Record: Deletes records from ServiceNow tables.
    • Wait for Condition: Pauses Flow execution until a specific condition is met.
    • Send Email / Send SMS / Send Notification: Sends email or SMS messages or triggers ServiceNow Notifications.
    • Log Action: Creates system logs for debugging and monitoring purposes.
    • Get Catalog Variables: Retrieves values of variables from ordered Service Catalog items.
    • Create Catalog Task: Creates Catalog Tasks for fulfillment workflows.
    • Copy Attachment: Copies attachments from one record to another.
    • Submit Catalog Item: Submits a Catalog Item order programmatically from within a Flow.
  • Importance of Out-of-Box Actions: Emphasizes the importance of leveraging out-of-box Actions before creating custom Actions, as they provide pre-built functionality and reduce the need for custom coding.
  • Custom Actions (Next Video): Prepares viewers for the next video, which will cover Custom Actions, explaining that Custom Actions are necessary when out-of-box Actions do not fully meet specific automation requirements.

Video 14: Custom Actions

This video demonstrates how to create Custom Actions in Flow Designer, extending Flow Designer's capabilities beyond out-of-box Actions.

Key points covered:

  • Custom Action Definition: Custom Actions are defined as reusable, user-defined actions that extend Flow Designer's functionality. They are created when out-of-box Actions are insufficient for specific automation needs.
  • Use Case: Incident Resolution PDF Attachment: Presents a scenario for creating a Custom Action to generate a PDF document of an Incident record upon resolution and attach it to the Incident.
  • Creating a Custom Action - "PDF Generation": Provides a step-by-step guide to create a Custom Action named "PDF Generation."
    • Navigating to Actions: Accessing the "Actions" tab in Flow Designer and clicking "Create New Action."
    • Action Properties: Setting the Action Name to "PDF Generation."
    • Input Parameters: Defining Input Parameters for the Custom Action:
      • Table Name: String type (Mandatory) - Specifies the table to query for PDF generation.
      • ID: String type (Mandatory) - Specifies the sys_id of the record for PDF generation.
      • Attachment Name: String type (Mandatory) - Specifies the desired name for the generated PDF attachment.
    • Script Step: Adding a "Script" Step to the Custom Action to implement the PDF generation logic.
      • Script Type: "Instance Script."
      • Script Input Variables: Defining Input Variables for the Script Step, mapping them to the Action's Input Parameters:
        • ID: Mapped to "Input - ID."
        • Table: Mapped to "Input - Table Name."
        • Name: Mapped to "Input - Attachment Name."
      • Script Code (PDF Generation API): Pasting JavaScript code that utilizes ServiceNow's PDF Generation API (sn_pdf_generator_api) to:
        • Query the specified table (inputs.table) for the record with the given sys_id (inputs.ID).
        • Generate HTML content for the PDF (in this simplified example, including "Short description").
        • Generate the PDF using generatePDF() method.
        • Attach the generated PDF to the record using uploadAttachment() method, using inputs.name for the attachment filename.
      • Script Output Variables: Defining Output Variables for the Script Step to return data back to the Action:
        • Attachment ID: String type - To return the sys_id of the created attachment.
        • Status: Choice List type ("Fail," "Success") - To return the status of the PDF generation process.
      • Output Mapping: Mapping the Script Step's Output Variables to the Action's Output Variables:
        • Status: Mapped from result.status.
        • Attachment ID: Mapped from result.attachmentId.
    • Action Output Parameters: Defining Output Parameters for the Custom Action:
      • Status: String type.
      • Attachment ID: String type.
  • Testing Custom Action: Demonstrates testing the Custom Action directly using the "Test" button, providing test input values for Table Name, ID, and Attachment Name, and verifying that the Action executes successfully and returns the expected Output values.
  • Publishing Custom Action: Shows how to publish the Custom Action to make it available for use in Flows.
  • Using Custom Action in a Flow - "Incident Generate PDF at Resolve" : Demonstrates using the newly created "PDF Generation" Custom Action in a Flow that triggers when an Incident is resolved.
    • Flow Trigger (Record Update - Resolved State): Sets the Flow trigger to "Record Updated" on the "Incident" table, firing when the Incident state is changed to "Resolved."
    • PDF Generation Action (Custom Action): Adds the "PDF Generation" Custom Action to the Flow.
      • Input Mapping: Maps Flow data to the Custom Action's Input Parameters:
        • Table Name: Statically set to "Incident."
        • ID: "Trigger Record - Incident Record - Sys ID."
        • Attachment Name: Dynamically constructs the attachment name using "Incident Number" and current time.
  • Flow Activation and Testing: Shows how to activate the Flow and test it by resolving an Incident and verifying that the Custom Action executes, a PDF document is generated, and the PDF is attached to the Incident record.
  • Action Reusability: Emphasizes that Custom Actions are reusable components that can be used in multiple Flows and Subflows, promoting modularity and efficiency in automation development.
  • Multiple Steps in Custom Actions: Notes that Custom Actions can contain multiple Steps (not just a single Script Step), allowing for more complex logic and workflows within a Custom Action itself.

This detailed breakdown provides a comprehensive understanding of Rohit's "Process Automation" series, covering Flow Designer fundamentals, advanced Flow Logic, and practical examples of automating various ServiceNow processes. It's a valuable resource for anyone learning Flow Designer and Integration Hub.

No Comments
Back to top