Workflow Variables

Input variables allow your workflow or atomic action to consume information when they are executed. If a workflow has input variables and you click Run, you will be asked to provide values for those variables before the workflow runs.

If an atomic action has input variables, you will be able to provide their values when editing its properties within a workflow.

Input variables can be optional or required. If they are required, the workflow will not run without input. If a variable is required for an atomic action, the workflow will not validate unless input is provided.

Check the Display on install wizard check box if you want users to be able to enter a value for this input variable during the installation of the parent workflow from the Exchange.

Output variables can be used by workflows and are most commonly seen in atomic actions. Many atomic actions consume input using input variables, perform a function, and then produce output in output variables. Output variables are available after an atomic action or sub-workflow runs and are usually used by subsequent activities.

Local variables only exist within an individual workflow or atomic action, and any values assigned to them do not persist across workflow runs.

If you do not provide local variable values to a workflow when it starts, the values are not accessible outside of the workflow after it ends. You can only get or set these values within the workflow itself. Local variables are useful as placeholders for assembling text for Webex Teams messages, for example.

Static variables only exist within an individual workflow. They are not available to other workflows.

A static variable has a pre-set value that can be modified with a Set Variables activity. The new value defined by the Set Variables activity persists across workflow runs.

You can update these two variables to provide feedback to the workflow user with information about the workflow execution:

• Workflow Result - Free-text property (can also be written in Markdown language) to communicate the results of the run and provide context, such as the "Investigation completed" string.

  • Needs to be explicitly set in all the cases where the workflow can end.

  • We recommend that you append these updates to a local variable as the workflow progresses.

  • For workflows with the intent of incident response, this property is automatically entered in the incident's worklog after the run completes.

• Workflow Result Code - Auto-populated string that indicates the outcome of the workflow.

  • Normally, the system derives this value based on the workflow result and implicitly sets it as follows:

    • Started - the workflow is running

    • Waiting-for-prompt-response

    • Start-error, Internal-error, Workflow-errored - the workflow failed

    • Partially-completed - the workflow did not fail, but at least one observable task did not succeed

    • Completed successfully - the workflow did not fail, and all observable tasks succeeded

    • Completed unsuccessfully - the workflow did not fail, but all observable tasks failed

  • As long as the workflow does not fail and completes, you have the option to override its result code by explicitly setting it as needed.

  • For workflows with the intent of incident response, this property is automatically used to set the status of the response task.