Workflow Concepts 1

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.

Updates to Workflow Stage Values

During an upgrade to the Fuji release, the system makes these changes to the Value field of records in the Workflow
Stage [wf_stage] table:
All entries are made lowercase.
All spaces and special characters are replaced with underscores.
These changes support internationalization of choice lists and enable workflows to display translated text in the
Stage field.
Workflow Concepts 4

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.

Workflows and Domain Separation

When domain separation is enabled, workflows and workflow activities inherit the domain of the user who publishes
or creates them. While workflows are managed by multiple tables, only the following tables are used for domain
separation features.
Workflow [wf_workflow]: used for delegated administration or process separation
Workflow Version [wf_workflow_version]: used for delegated administration or process separation
Workflow Context [wf_context]: used for data separation

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 domain support is available starting with the Eureka release.

Workflows and Delegated Administration

Workflow records in the Workflow [wf_workflow] and Workflow
Version [wf_workflow_version] tables are considered processes.
Delegated administration allows child domains to inherit workflows
from higher up the domain hierarchy and to override them with
domain-specific versions if necessary. A user in a child domain may
check out but not copy a workflow from a parent domain. When a user
in a child domain checks out a workflow from a parent domain, the
system creates a version of the workflow in that user's domain. This
new version is a unique record in the Workflow [wf_workflow] table.
Workflow delegated administration in a sample
domain hierarchy After the user publishes this new workflow, other users in the child
domain use the new workflow, which overrides the workflow from the
parent domain. The original workflow in the parent domain is no longer visible to users in the child domain.
For example, suppose a managed service provider (MSP) hosts ITSM services for several companies including
ACME and Initech on a single instance. As administrators, the MSP creates a Service Catalog Request workflow that
applies to all domains because it was created in the TOP domain, which is the highest domain in the domain
hierarchy. This workflow overrides the global Service Catalog Request workflow and specifies that all Service
Catalog requests over $750 require approval. Because of delegated administration, every domain in the hierarchy
sees and uses this workflow. Now suppose the ACME domain requires a different approval policy where requests
over $500 require approval. The MSP creates another version of the Service Catalog Request workflow in the
ACME domain. This workflow overrides the version in the TOP domain and only applies to users in the ACME
domain.
Workflow Concepts 7

Workflows and Data Separation

Workflow records in the Workflow Contexts [wf_contexts] table are
considered data. Data separation restricts workflow contexts to users
who are either in the same domain of the workflow or are members of
a parent domain. While a user in a parent domain can see running
workflows in a child domain, a user in a child domain cannot see
running workflows in a parent domain. If necessary, administrators can
use visibility or contains domains to expand who can see
domain-specific data.

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 Engine Operation Order

The workflow engine runs in a predefined order relative to business rules and database operations. The Run after
bus. rules run workflow property defines if a workflow is Default or Deferred. Depending on the operations
performed, you may need to explicitly update the current record using the current.update() method.
This diagram shows the workflow engine order of operations and provides guidelines on when to use
current.update(). For a more general overview of engine operation order, see Execution Order of Scripts and
Engines.
Workflow Concepts 8

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 Operations Dashboard

The Workflow Operations Dashboard displays information to help workflow administrators review and improve
workflow performance. This dashboard is available starting with the Fuji release.

Workflow Run Time Metrics

Administrators can enable the collection of workflow run time metrics by setting Estimated Run Time (ERT)
properties. Administrators can use these metrics to determine if workflows are running longer or shorter than
expected and to identify errors in workflow processing. The system displays run time metrics on the Workflow
Operations Dashboard. See Workflow Run Time Metrics.
Administrators can collect workflow run time metrics starting with the Fuji release.
Workflow Concepts 9

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 [wf_workflow] The master records of workflows.

Workflow Context [wf_context] Individual instances of a workflow being used.

Workflow Execution Synthetic current records for workflows that run on Global".
[wf_workflow_execution]

Workflow Instance [wf_workflow_instance] Connections of workflows to subflows.

Workflow Version [wf_workflow_version] Particular versions of a workflow, either published versions or versions that have been checked out.

Activities

Activity Designer [wf_element_activity] Custom activity definitions.

Activity Variables [wf_activity_variable] Variables for activities.

Workflow Activity [wf_activity] Activities as they are being used in workflows.

Workflow Activity Definition Definitions of activities that can be used in a workflow.

[wf_activity_definition]

Workflow Executing Activity [wf_executing] Individual instances of activities being performed in active contexts.

Workflow components

Element Provider [wf_element_provider] Template definitions for custom activities.

Group approval [sysapproval_group] Group-level approvals.

Workflow Condition [wf_condition] All of the defined conditions in workflows.

Workflow Element Definition Parent table for activity definitions.

[wf_element_definition]

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.

Workflow SC Variable [wf_variable] The Service Catalog variables for a workflow.

Workflow Schedule [wf_workflow_schedule] Definitions of the times to run specific workflows.

Workflow Transition [wf_transition] All of the defined transitions in workflows.

History

Workflow Activity History [wf_history] The history of executed activities.

Workflow Log Entry [wf_log] All of the events and history of the workflow.

Workflow Transition History The history of executed transitions.

[wf_transition_history]

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.

Workflow Stage [wf_stage] Definitions of stages used by workflows.

Article Sources and Contributors 11

Article Sources and Contributors

Workflow Concepts Source: http://wiki.servicenow.com/index.php?title=Workflow_Concepts Contributors: David.Bailey, Debbie.bodinger, Emily.partridge, Fuji.publishing.user, Guy.yedwab,
Joseph.messerschmidt, Julie.phaviseth, Peter.smith, Steven.wood, Suzanne.smith, Vaughn.romero, Virginia.kelley

Image Sources, Licenses and Contributors

Image:Routine Change.png Source: http://wiki.servicenow.com/index.php?title=File:Routine_Change.png License: unknown Contributors: Fuji.publishing.user, Guy.yedwab
Image:Wf-activity.png Source: http://wiki.servicenow.com/index.php?title=File:Wf-activity.png License: unknown Contributors: Fuji.publishing.user, G.yedwab
Image:Wf-condition.png Source: http://wiki.servicenow.com/index.php?title=File:Wf-condition.png License: unknown Contributors: Fuji.publishing.user, G.yedwab
Image:Wf-transition.png Source: http://wiki.servicenow.com/index.php?title=File:Wf-transition.png License: unknown Contributors: Fuji.publishing.user, G.yedwab
Image:Workflow_field.png Source: http://wiki.servicenow.com/index.php?title=File:Workflow_field.png License: unknown Contributors: Fuji.publishing.user, Guy.yedwab
Image:Warning.gif Source: http://wiki.servicenow.com/index.php?title=File:Warning.gif License: unknown Contributors: CapaJC
File:Workflow_editor_domain.png Source: http://wiki.servicenow.com/index.php?title=File:Workflow_editor_domain.png License: unknown Contributors: Fuji.publishing.user,
Vaughn.romero
Image:workflow_and_delegated_administration.png Source: http://wiki.servicenow.com/index.php?title=File:Workflow_and_delegated_administration.png License: unknown Contributors:
Fuji.publishing.user, Vaughn.romero
Image:workflow_and_data_separation.png Source: http://wiki.servicenow.com/index.php?title=File:Workflow_and_data_separation.png License: unknown Contributors:
Fuji.publishing.user, Vaughn.romero
Image:WF_Engine_Order_Diagram.png Source: http://wiki.servicenow.com/index.php?title=File:WF_Engine_Order_Diagram.png License: unknown Contributors: Joseph.messerschmidt