Creating a Workflow

From ServiceNow Wiki
Home > Administer > Workflow > Workflow Administration > Creating a Workflow
Jump to: navigation, search
               Workflows               
Related Topics
  • Orchestration
  • Orchestration VMWare Support
  • Service Catalog Workflows
    Knowledge.gif Get the Book

1 Overview

Users with the workflow_admin or workflow_creator roles can use the Workflow Editor to create workflows. If you are designing the workflow as part of an update set process, see Moving Workflows with Update Sets before creating the workflow. Also, make sure you understand how workflow scoping can affect a workflow's access to information. The scope of a workflow cannot be changed after it is created.

Note
Note: For information on creating workflows in Eureka and Dublin, see Creating Workflows in Versions Prior to Fuji.


2 Creating a Workflow

When you create a new workflow, the editor presents key properties for configuration. Additional properties are available for configuration after you submit the workflow. For details, see Configuring Additional Properties.

To create a new workflow:

  1. Navigate to Workflow > Workflow Editor.
    The Welcome tab displays links to workflow documentation and other related resources. If ServiceNow Orchestration is activated, the welcome screen contains resources for that feature as well.
  2. Select the Workflows tab in the palette, and click the + icon.

    Click the + to create a new workflow

    A tabbed form appears for configuring the workflow.

    Workflow properties tabs

  3. Complete the fields in the General, Schedule, and Documentation tabs.
  4. Create the workflow by clicking Submit in any tab.
    When the workflow is created, it contains Start and End activities.

    New workflow layout

  5. In the title bar, click the menu icon (View workflow menu) and select Properties.
  6. Complete configuration of the additional workflow properties.
  7. Build the workflow by dragging activities onto the canvas and configuring activity properties.
    See Adding Workflow Activities for details.
  8. If your workflow contains branches of activities, verify that the workflow ends correctly.
    For more information, see Ending Workflows with Multiple Branches.
  9. Validate the workflow.
    Workflow validation tests the workflow for potential issues that might cause it to fail, such as missing subflows or disconnected transitions. A workflow validation report lists the results of each validator and provides enough information to trace problems and make any changes that are necessary.
  10. Publish the workflow by clicking the menu icon and selecting Publish.
    The workflow is then activated and can be used according to the defined properties.
Note
Note: Publishing a new version of a workflow does not change any workflow contexts that were created before the new version is published.


2.1 General

Field Description
Name A unique name to identify the workflow. Workflows cannot be created with the same name as an existing workflow, starting with the Eureka release.
Table The table for the workflow to run on. Workflows that run on specific tables can still interact with other tables. Select Global [global] to run the workflow on all tables.

All users who edit the workflow must have access to the necessary tables and domains.

Order Numeric value that determines the order of the workflow, relative to other workflows. Workflows are evaluated in order from the lowest order number to the highest. A workflow runs if it is the first to match conditions.
Max activity count [Required] The maximum number of activities performed by the workflow. This value is used to prevent infinite loops and is set to 100 by default. When the stated maximum count is reached, the workflow is canceled. If this field is blank, the maximum count is set to -1, and the workflow is canceled.
Activity pinning List of options that control updates to custom activities at the workflow level. Pinning protects custom activities from being updated automatically when downloaded from the ServiceNow Store. For more information, see Activity Pinning. Pinning is available starting with the Fuji release. The possible options are:
  • Set by activity: Allows all activities in the workflow to use their own pinning settings. This is the default pinning option.
  • Pin all activities: Pins all activities in the workflow to their current version.
  • Unpin all activities: Allows all activities in the workflow to be updated.
Application [Read-only] Scope of this activity. For more information, see Application Scope.
Accessible from [Read-only] Scope restrictions for this workflow. Possible settings are:
  • All application scopes: Workflow is accessible to all application scopes.
  • This application scope only: Workflow access is limited to the scope named in the Application field.

For more information see Workflow Scope.

Checked out [Read-only] When the workflow was checked out. Automatically set by the Checkout action in the workflow menu.
Checked out by [Read-only] The user who has this workflow checked out. This value is automatically set by the Checkout action in the workflow menu.
Published [Read-only] Check box to indicate whether the workflow has been published. Automatically set by the Publish action in the workflow menu.
If condition matches When the condition evaluates to true, the workflow launches in an active context:
  • None: The workflow engine will not automatically start the workflow. To run this workflow, write a script and manually start the workflow.
  • Run the Workflow: The default value. The workflow engine starts the workflow if the information in the Condition field matches a record that is inserting into the table.
  • Run if no other workflows match yet: The workflow engine only starts the workflow if no other workflows are running on a specific record. For example, there are four workflows inserted into the Incident table, which have a condition such as short_desc contains test. A new workflow, which has If condition matches is set to Run if no other workflows match yet, only runs if none of the four workflows have started running on the Incident record.
Condition A condition builder for specifying workflow conditions that trigger the behavior selected from the If condition matches list.

2.2 Schedule

Create a schedule for this workflow using the schedule builder.

Field Description
Delivery based on The schedule type for this workflow. Possible types are:
  • User-specified duration: Duration based on a user-specified value. This is the default schedule type.
  • Relative duration: Duration calculated from a preconfigured schedule, such as 8-5 weekdays.
Expected time User-defined interval. This field is available when the schedule type is User-specified duration.
Schedule Preconfigured schedule that determines when this workflow runs.
Timezone Time zone for this instance.

2.3 Documentation

The Documentation tab displays the name of the current workflow's author and a description of the workflow's purpose.

3 Configuring Additional Properties

To finish configuring your new workflow, submit it. Then reopen the Workflow Properties form by clicking the information icon View workflow properties in the title bar or clicking the menu icon Open context menu and then selecting Properties. These additional properties are available for configuration:

3.1 Inputs

The Inputs tab lists all the activities in the current workflow that input data, the data type, and the default value. To create a variable, click New.


Data inputs from activities in the current workflow


Field Description
Label Column label
Reference Name of a field used as a reference field.
Type Data type.
Default value Default value for this input data

3.2 Stages

Field Description
Stage field The field on the table that will be updated with the stage information. If this value is not specified, the default stage field for the table is used. For more information, see Using Workflow Stages.
Stage Rendering The renderer to use when displaying stage icons on a form or list view. For more information about renderers, see Rendering Workflow Stages.
Stage order The order of workflow stages when you view a workflow field in a list. Select Computed to let the workflow engine compute the stage order from the order of execution in the workflow. Select User Specified to use the Order field from that workflow's stages.

3.3 Estimated Runtime

The Estimated Runtime tab opens the controls for configuring the ERT for the workflow. Core workflows included in the base system are not configured for estimated run time by default. All new workflows are configured with default ERT values automatically. You can edit existing run time estimates or configure new ones for any workflow. For details about how estimated run times are configured and calculated, see Workflow Run Time Metrics.

Field Description
Requires ERT Check box to indicate that this workflow requires an estimated runtime configuration. You can use the ERT calculations to determine if workflows are running longer or shorter than expected and to identify errors in workflow processing. By default, new workflows require an ERT.
Estimated Run Time The initial estimate for the workflow's run time.
Number of data points [Read only] The number of times the system has compared the estimated run time to an actual run time result.
Outlier Percentage Threshold for ERT [Required] The percentage deviation from the estimated run time that identifies an outlier workflow run time. The system uses a default value of 20. For more information, see Identifying Outlying Run Times.

3.4 Version

The Version tab lists all versions of the current workflow. When you create a new workflow, this list is empty.


Current workflow versions


3.5 History (Past Contexts)

The History tab lists all the contexts for the current version of the current workflow. This list is empty until the workflow has run.


Contexts for the current version of the current workflow

4 Creating Workflows in Versions Prior to Fuji

5 Canceling Workflows

You can use a script action to cancel executing workflows. This can be helpful in cases where a workflow must be canceled in response to an event or where a user must manually cancel a workflow.

For details on the script, see cancelContext(context).

6 Ending Workflows with Multiple Branches

A workflow is complete when it reaches the End activity, even if there are still active branches of the workflow in progress.

For example, the following figure shows a workflow with two branches that execute independently. When Task 1 and Task 2 of Branch B are completed, the workflow is marked complete even if the Branch A tasks are not completed.


Wf-problematicworkflow1.png


To ensure that both branches are completed, add a Join activity to resolve the branches. When one branch reaches the join, the workflow waits for the other branch. When both branches are complete, the workflow reaches the end. The Incomplete condition is met only if one of the branches cannot be completed.


Wf-problematicworkflow3.png

7 Editing Published Workflows

After the workflow is published, you can edit it by clicking the menu icon View workflow menu in the title bar (gear icon in releases prior to Fuji) and selecting Checkout. A new workflow version is then created and assigned to you. If you are in a different domain than the published workflow, the new workflow version is created in your domain starting with the Eureka release.

You cannot check out or delete workflows that are associated with a read-only application file starting with the Eureka release.

8 Sample Workflows

Because of the flexibility of workflows, you can create many different types. The following list contains several workflow samples:

Was this article helpful?
Yes, I found what I needed
No, I need more assistance