It is ServiceNow new release season! With the London release in Early Access, we will cover some of the features newly available to application developers. In this post, I will discuss one very specific topic - new ways in which Flows can be initiated. When originally released in Kingston, there were two ways to start a flow: on change or insert of a record or via a schedule. That has expanded, increasing the flexibility of Flow logic.
Start a Flow from Script
A big change in Flow Designer architecture is the ability to start a flow from server script. This is accomplished via the new API sn_fd.startAsync(scopedFlowName, flowInputs).
This API allows you to start any flow from any server script, so the possibilities have expanded greatly. In order to start this flow, you need to know the internal name of the flow qualified with the scope prefix.
In the above example, the value that would be passed to the first parameter would be “sn_bm_spoke.benchmark_recommendation_evaluator”. The internal name of the flow is “benchmark_recommendation_evaluator” and it is contained in the “Benchmarks Spoke” which has a prefix of “sn_bm_spoke”. If you want to find the scope prefix that you don’t easily have to hand, you can look that up in the Application Manager at System Applications > Applications.
The second parameter is a hashmap style JSON object that contains the input parameters for the flow. Exactly what is contained in this object will depend on the trigger type of Flow being started. Flows with record triggers will need that information passed in to satisfy what would be expected from a system trigger. More details on that later.
Start a Flow from Another Flow
By default, you can call subflows from flows using the subflows menu. However if it makes sense with your architecture, you can now begin a flow directly from another flow. This requires a little bit of setup in your Flow Designer window but after that you will have other full Flows available in the way that Actions or Subflows are currently available.
First you want to go into “More actions” (aka the three dot icon in the upper right) and select “Configurations”.
In the next window, turn the “Show triggered flows” option on. When you do that, flows will then be visible in the list to add to your flow. Much like the API triggered flows, it will be the responsibility of the calling flow to pass in necessary information. If you are calling a record triggered Flow, you must pass a valid record of the correct type wherever you invoke it.
Start a Flow from Service Catalog
Note: this requires a plugin not activated by default in the baseline system - the Flow Designer support for Service Catalog plugins, com.glideapp.servicecatalog.flow_designer.
When the plugin is activate, this will make a new Trigger type available, Service Catalog. This will allow a Flow to be triggered based on specific values and variables of the Service Catalog request. This is akin to the conditions that can be set on record based triggers but is specific to Service Catalog and can drill into the specifics of the request.
Start a Flow from Metric Base
Note: this requires Metric Base to be activated on the instance, which it is not in a baseline instance. In addition, Metric Base requires a separate subscription for the functionality and is not available in personal developer instances.
In London, Flows can be initiated by Metric Base Triggers. My knowledge of Metric Base is limited but this basically means you can start flow when:
- the series data reaches a threshold
- when a trend emerges and is on track to reach a threshold
- the data collection experiences a gap
With these I can see use cases for all these. Imagine a case where temperature and humidity data was being collected from sensors all around a building. If either gets out of certain tolerances, then initiate a flow to file an incident with facilities and send notifications. If the data flow is interrupted for a time period, start another different flow. If you are in a production situation where you are gathering Metric Base data, it might be an interesting exercise to think about what actions you would want triggered by that data and whether a flow is feasible for that action.
As time goes on, we will explore more developer-facing features of the London release. If you don’t already have a London PDI feel free to claim one and explore for yourself. Happy developing!