Creating and Using Subflows in ServiceNow

The basics for subflows is documented in this ServiceNow Wiki article.

Notes to bear in mind when defining and using subflows:

• Create the subflow prefaced with “Subflow” in order to distinguish that subflow from a regular workflow. Otherwise you can’t tell in the list whether the workflow is a primary or sub.
• Subflows are available as workflow activities when creating a primary workflow.
• Subflows must be created using the same table as the primary workflow.
• Input fields:
  • The fields must be mapped into the record for the table the subflow is created. Must exist in the same context.
  • If a literal, no quotes needed.
• The workflow scratchpad in the primary workflow is not shared with the subflow and vice versa.
  • Data is received as “input fields”.
  • Data is returned using “return codes”.
  • If scratchpad variable is used for receiving a “return code”, it must be initialized before being referenced in the Return Code activity.
• Return codes:
  • Can return a string (or in the form of a Javascript $() style variable).
  • Literals do not need quoting.
• Change considerations:
  • Subflows are dynamically executed. Tasks already in process will execute the current subflow when called unless the subflow is already in execution mode (i.e. already attached to the task).
  • Workflows are statically executed. Tasks already in process will execute the legacy workflow since it is already in progress.

Example: A simple catalog item is created with a workflow associated that calls a subflow to return whether a manager’s name begins with the letter “A”. The return from the subflow would be either “yes” or “no”. This functionality would be referenced in this catalog item and others as a standard validation on other catalog items that have their own unique workflow, but requiring the same “A” validation on the manager’s name.

The system property “glide.workflow.enable_input_variables” must be set to true in order to enable input variables in subflows.