Professional Documents
Culture Documents
Workflow Concepts
Workflow Concepts
Workflow Concepts
Overview
Using the ServiceNow Workflow Editor, you can:
Modify core activities and conditions.
Create custom activities and reuse the data for other workflows.
Download activity packs from the ServiceNow Store and create packs for upload.
Edit workflows graphically.
Define transitions between workflow activities.
For the table that corresponds to the workflow, customize business rules.
Summarize workflow progress through stages.
Validate workflows to identify potential problems.
Publish workflows for other users.
Access various workflow modules.
Edit multiple tables without needing to directly modify them.
You must be an administrator or a user with a workflow role to use the Workflow Editor.
Workflow Editing
The Workflow Editor is a user interface for defining workflows. During workflow editing or while an unpublished
workflow is running, only the person who checked out the workflow can view the changes.
After a workflow is published, it is available to other users. The workflow moves through the process as defined in
the Workflow Editor. The entire workflow is represented in one screen. For example, this is the Routine Change
workflow included with Change Management Workflows:
Workflow Concepts 2
Workflow Activities
The workflow activity contains instructions that are processed by the workflow. This can include performing scripts,
manipulating records, waiting for a set period of time, or logging an event. Workflow conditions determine whether
or not the activity is performed. Activities can be added, removed, or rearranged. Transitions can be drawn between
activities.
This is an activity that triggers a notification:
For more information on available activities and their behaviors, see Using Workflow Activities.
Exit Conditions
After a workflow activity is performed, the workflow condition is evaluated to determine which transition is
activated.
This condition determines behavior based on a change being approved or rejected:
Transitions
After the workflow condition is evaluated, the workflow transition determines which activity is performed when the
workflow condition is met.
This is a transition that always leads from the Change Approved script to the Change Task activity:
Workflow Concepts 3
Workflow Stages
Workflows can provide a summary of workflow progress by updating any field designated as a Stage field. For
example, the Incident [incident] table has an Incident state field that indicates progress, whereas the Service
Catalog uses the Stage field.
If the field is a workflow field, it displays an icon to indicate the workflow's progress, as with the Service Catalog's
Stage field. For more information, see Using Workflow Stages.
Stage Sets
You can create stage sets, which are named groups of stages that are commonly used together. These stage sets can
be used in any number of workflows on different tables. A single stage set usually represents a process, such as the
stages required to display the progress of a service catalog request. See Using Workflow Stage Sets.
Workflow Versions
To prevent users from making changes to a workflow which impact other users of the system, workflows must be
checked out before they can be edited. Only one user can check out a workflow at a time. When a workflow is
checked out, changes only apply to the user who has the workflow checked out. Other users can continue to use the
published workflow. After the changes are complete, the workflow can be published so that it is available to all
users.
Note: Because each workflow has a unique sys_id, different workflows can have the same name. This is typically expected in a
domain-separated environment where users in different companies cannot see each other's workflows because they are in different
domains. However, this can lead to confusion in other environments. In general, give a unique name to each workflow to prevent
workflow designers making changes to the wrong workflow.
Modifying Workflows
When a new version of an existing workflow is published, the changes are not applied to running workflow contexts.
Any currently running workflow context continues using the workflow version that was available when the
workflow started. The next time the workflow runs, it uses the updated, published version.
Workflow Validation
Validate a workflow before you publish it to identify potential problems that can cause the workflow to fail.
Validators look for issues such as multiple End activities, broken transitions, incorrect table references, and missing
subflows. A workflow validation report indicates the severity of each finding in its results and provides a useful
description of the issue. You can run validation on a workflow directly from controls in the Workflow Editor.
Workflow Scope
Workflow application scope determines the access that an application has to the information in a workflow,
specifically to the data contained in the activities in that workflow. When a workflow is created, it inherits the
application scope from the gear menu for the logged in user. This scope cannot be changed in the Workflow Editor.
When the workflow executes, it runs in this scope and can only be called from a different application if the
workflows accessibility setting permits access to all scopes (public).Otherwise, the workflows application scope is
private to the application.
Note: Any script that is created in the workflow canvas, such as an advanced script in an If activity, runs in the scope of the
workflow. All core activities provided in the base system or for Orchestration run in the scope of the workflow.
Restrictions
During runtime, publicly scoped workflows can access other application resources, as long as these resources are set
to be accessible to all application scopes. Privately scoped workflows in a private application scope can only access
resources private to its scope. Due to scope access boundaries, any privately scoped workflows that make calls out to
other scoped resources fail with either an exception or a hung activity while waiting for returned results. This occurs
when making calls to these common global resources:
ECC queues
Tasks
Approvals
Workflow Concepts 5
Events
SLA timers
Timers
Script includes
Business rules
Workflow APIs.
As you design your workflows, validate the visibility and accessibility of all resources prior to deployment.
For general information on how application scoping is used in the ServiceNow system, see Application Scope. For
information on how to configure the scope for a workflow, see the field description table for workflow property
fields.
Custom Activities
Custom activities run in their own scope, even if it is different from that of the workflow. The scope of a custom
activity can be private or public. Any script that runs inside a custom activity with a scope can only access outside
artifacts that are within the scope of that activity or artifacts that are configured to run in any scope. Conversely, an
outside artifact can only access the script inside that private activity if the outside artifact is running in the same
scope. Activities with public scopes can interact with outside artifacts in any application scope.
You can use private activities as part of a workflow that has a public application scope. These activities are protected
from reaching outside of the workflow or from being reached from outside the workflow. For details about setting
application scoping for custom activities, see the field description table for the appropriate activity template.
Note: Custom activities uploaded to the ServiceNow Store must be configured as accessible to all application scopes.
Note: The Workflow Version table [wf_workflow_version] table does not contain a domain field; Workflow Version records inherit
their domain from the parent Workflow record.
The Workflow Editor displays a workflow's domain in the title bar after the workflow name.
Workflow Concepts 6
Workflow data separation in a sample domain For example, when an ACME user requests something from the service
hierarchy catalog, a Service Catalog Request workflow context is created in the
ACME domain. Similarly, a service catalog request from an Initech
user creates a workflow context in the Initech domain. An MSP user in the TOP domain can see both workflow
contexts because it is the parent domain for both the ACME and Initech domains. However when an ACME or
Initech user logs in, data separation prevents them from seeing each other's service catalog requests. This is expected
behavior because each workflow context contains data specific to that domain, such as the item requested and the
request's approval history.
Workflow Permissions
When a user starts a new workflow, the workflow runs with that user's domain and credentials. The workflow
preserves these values until an activity causes the workflow to wait, such as an approval activity waiting for approval
or rejection. When the stopped workflow resumes, such as when a user approves a request, the workflow uses the
credentials of the approving user but continues to run within the domain of the original user.
Workflow Caching
The workflow engine caches commonly-used published workflows to improve performance. Caching significantly
reduces the number of database queries per workflow. By default, the engine caches up to 300 unique workflow
versions. Caching very large workflows may reduce this number as the cache size cannot exceed the Java Virtual
Machine heap size. Workflow caching is available starting with the Eureka release.
To change the maximum number of cached workflow versions, navigate to Workflow > Administration >
Properties and modify the value of the The max number of models that will be concurrently held in the LRU
cache (glide.workflow.model.cache.max) property. You must restart the instance to apply this change.
Workflow Tables
For full flexibility, workflows store information over a number of different tables. Usually these tables are not
interacted with one-by-one; rather, use the Workflow Editor to edit workflows. The following lists are provided for
reference purposes.
Table Description
Workflows
Column Renderer [column_renderer] A renderer widget for a stage column. Stage renderers are written in Jelly as a UI Macro. The
default is Workflow-Driven which will cover most workflow related stage scenarios.
Workflow Execution Synthetic current records for workflows that run on Global".
[wf_workflow_execution]
Workflow Version [wf_workflow_version] Particular versions of a workflow, either published versions or versions that have been checked out.
Activities
Workflow Executing Activity [wf_executing] Individual instances of activities being performed in active contexts.
Workflow components
Workflow Estimated Runtime Configuration Performance data of completed workflows. This table is available starting with the Fuji release.
[wf_estimated_runtime_config]
Workflow Queued Command [wf_command] Temporary internal storage for workflows that are currently executing.
History
Workflow Log Entry [wf_log] All of the events and history of the workflow.
Stages
Stage Default [wf_stage_default] Definitions of default stage fields for tables to use.
Stage Set [stage_set] A named set of stages that can be used to populate workflow stages for multiple workflows.
Workflow Concepts 10
Stage Set Entry [stage_set_entry The stages that belong to a named stage set.
Stage Set for Table [stage_set_table] Defines a relation ship of a Stage Set to a table so that that stage set can be used as the default
stages when a new workflow is created for the table. This replaces the wf_default_stage table and is
now the view that shows when you click Default Stages (by table) in the menu.