Domain separation and Workflow

This is an overview of domain separation and the Workflow application. Domain separation enables you to separate data, processes, and administrative tasks into logical groupings called domains. You can then control several aspects of this separation, including which users can see and access data.

Overview

Support: Data only

When domain separation is enabled, workflows and workflow activities inherit the domain of the user who publishes or creates them.

How domain separation works in the Workflow application

While workflows are managed by multiple tables, only the following tables are used for domain separation features:

Workflow [wf_workflow] and 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.

Workflows and delegated administration

Delegated administration allows child domains to inherit workflows from higher up the domain hierarchy and to override them with domain-specific versions if necessary.

Processes are visible upwards. A child domain can see workflows in a parent domain. — Figure 2. Workflow and delegated administration

Workflow records in the Workflow [wf_workflow] and Workflow Version [wf_workflow_version] tables are considered processes. 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. 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, 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 Change Request - Emergency 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 Change Request - Emergency workflow and specifies that emergency change requests require approval from the CAB approval group. 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 emergency change requests require approval from the emergency CAB approval group. The MSP creates another version of the Change Request - Emergency workflow in the ACME domain. This workflow overrides the version in the TOP domain and only applies to users in the ACME domain.

Workflow permissions

When a user starts a new workflow, the workflow runs with that user's domain and credentials.

The workflow preserves a user's domain and credentials 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.

Contents