Workflow inputs

What is a workflow input?

A workflow input is a string variable, which can be defined within a child workflow and to transfer data from a parent workflow.

When do I need a workflow input?

An input can be necessary, if a value, which was created within the parent workflow, needs to be used within the sub workflow and no existing form field could be used to write that value to.

Workflow inputs are only available in workflows which are not used for Catalog items (using the table Requested Item = sc_req_item). Catalog item workflows use variables defined in the form and do not display the inputs tab in the workflow properties.


As I struggled with the documentation from ServiceNow about these input variables, I wanted share an example how I used an input.

I have two workflows:

  1. Parent: Change Request – System Build
  2. Child: Change Request – System Build Tasks

I have no field in the change request, where the device name is entered separately, therefore I had to extract it from the description.

I have used the scratchpad to store the extracted value.


Now I have the name of the device in the scratchpad variable devicename of the parent workflow (Change Request – System Build).

As scratchpad variables are only available in the context of the workflow it is running in, I cannot use this variable in the subflow. Now I need to have an input variable in the subflow.

I checkout the subflow (Change Request – System Build Tasks), went to Properties > Edit Inputs and created this input:

When I now open the subflow activity in the parent workflow (where I call the subflow), then the devicename_task field is shown.


I give the value from the scratchpad variable to this input variable of the subflow by entering ${workflow.scratchpad.devicename}.

Within the subflow I then can get the value of the input variable with this command:
(Attention! it is the column name, I need to use!)

That’s it.

Here is also a good summary about variables in a workflow.



Workflow – Check Blackout Conflict

During our Change Management implementation in ServiceNow we realized that we need to change the Change Request – Normal workflow to check if the change is scheduled during Blackout. If that is the case, we wanted to have one additional approval.

As there was no default option to check for the Blackout conflict, we used this script to get a ‘yes’ or ‘no’ answer within the IF activity.

var count = new GlideAggregate('conflict');
var conflicts = 0;
conflicts = count.getAggregate('COUNT');

answer = ifScript();

function ifScript() {
if (conflicts>0) {
return (‘yes’);
return (‘no’);