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.

Figure 1. 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 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.