Flows and Subflows

#Flow Designer

Brittany Navin

5 minute read

Flow vs Subflow

A few months ago you might have “met” me when you read my blog post on GlideRecord vs GlideRecordSecure. For those that haven’t read that blog post, let me introduce myself! I’m Brittany, a Sr. Software Engineer at ServiceNow. I work on the backend of the Applicaton Template Framework. Templates power App Engine Studio and allow customers to quickly create experiences, logic, data and security functionality in their applications without writing any code. In executing templates over and over, users can create new “copies” of functionality for their applications.

There’s a lot of backend code that powers the Application Template Framework and App Engine Studio, but one of the core platform features that we make use of is Flow Designer Flows. For those that do not know, Flow Designer provides two types of flows: Flows and Subflows. In this blog post I will outline the main differences between Flows and Subflows.

Flows

Simply put, Flows allow users to execute some action(s) based on a given trigger. They are great if you want to create a “scheduled job”, where some actions are taken on records automatically.

Flow Actions

Actions that can be executed in a Flow include:

  • Updating a record
  • Deleting a record
  • Sending a Slack or Microsoft Teams message
  • Creating Docker containers
  • Logic (if this action occurs, then that action can be taken)
  • Password resets
  • A custom action developed by you
  • Installing applications
  • Running an ATF suite
  • Many, many more options (some of which can be installed using IntegrationHub)

Flow Triggers

Triggers conditions used to execute a flow and its associated actions include:

  • Specific dates/times (yearly, daily, monthly, hourly, each minute, each second)
  • Record(s) created/updated
  • Service Catalog item is requested
  • Specific e-mail is sent to the instance
  • An SLA Task

Coincidentally, the FlowAPI also provides users with a way to execute a Flow programmatically via script: the executeFlow() method. If you use the FlowAPI to execute the flow, you can pass in inputs to be used by the Trigger, if desired. In practice, I’ve seen this practice used less often because the triggers available for use in Flows are plenty good to get the Flow executed. However, I’m sure there are some weird edge cases out there that might require programmatic Flow execution.

Subflows

Subflows are just like Flows, but without triggers. Subflows are executed (“triggered”) programmatically via a script (and more options, discussed later). You can use the FlowAPI to run the executeSubflow() function in order to execute the Subflow via script.

Just like in the Flow action list above, Subflows will also contain actions. Different from Flows, you can provide the Subflow with inputs & associated values to be passed directly into the Subflow action(s). Additionally, the Subflow can provide output(s) from the Subflow actions, if desired. This is handy if you want to access the value of something that was created or modified in your Subflow.

For example, say I had a Script Include called AnimalShelterAdopter. When a person adopts an animal something triggers the adoptViaInternet() function inside of Script Include to execute. In this adoptViaInternet() function, I had some complex code that works on readying the animal for adoption and then executes a Subflow containing the following actions:

  • removes animals from the available_animals table
  • adds the animal & owner adopted_animals table
  • sends an adoption confirmation email to the new owner

For example, this Script Include will look like so:

var AnimalShelterAdopter = Class.create();
AnimalShelterAdopter.prototype = {
    initialize: function() {
    },

	adoptViaInternet: function() {
		// Some imaginary code here

		var inputs = {'animal':'animal_sys_id_here'};
		var fifteenSeconds = 15000;

		// Execute the Subflow
        // Note: you can find the "internal name" of your Subflow (for the first param of the executeSubflow function) in the Flow Designer home page
		var outputs = sn_fd.FlowAPI.executeSubflow('subflow_application_scope_here.flow_name_here', inputs, fifteenSeconds);

		gs.log(JSON.stringify(outputs));
	},

    type: 'AnimalShelterAdopter'
};

The Subflow mentioned in my example above can be re-used in other functions in my Script Include, like adoptViaShelterVisit() or adoptViaFostering(), and I only need 1 line of code to do this.

Additionally, Subflows can be included and executed inside of Flows (but not vice-versa). Woah, flow-ception! This is an incredible way to compartmentalize a Flow into many smaller pieces. This is also a wonderful tool for debugging a large Flow, because you can “test” each Subflow independently of one another.

Putting It All Together

How are Flows and Subflows the same?

  1. In both Flows and Subflows, multiple actions can be used to accomplish tasks (and you will have access to the same selection of actions in both, I believe). The output of one action can be fed into the input of another action. That’s pretty cool if you need to make lots of dependent records.
  2. Coincidentally, flows and subflows can both be run programmatically.

How are they different?

  1. Flows are executed when trigger conditions are met (or via script); subflows are executed programmatically (either inside of an existing Flow or via script) and do not have trigger conditions.
  2. Flows can contain Subflows, but not vice versa.
  3. Inputs & values can be passed directly into Subflow actions, whereas inputs & values are passed directly into triggers for Flows.
  4. Subflows allow you direct access to output, whereas Flows do not (caveat: easily, there’s always a way with code).

Documentation Quick Reference

In case you want to dive in deeper, here are some links that will help you:

Comments