This document describes how to work with approval workflows.
The content is organized under the following sections:
CentraSite's approval-management framework enables you to review a request and approve or reject the request when certain time events occur in the registry. For example, you might require a system architect to review and approve all assets before they are switched to a productive state.
To impose an approval process on a change time event, you create an approval policy for the event. An approval policy is a policy that contains one of CentraSite's built-in approval actions.
Note:
In this guide, the term approval policy is used
to generally refer to policies that you use to perform approvals. Technically
speaking, an approval policy is no different than an ordinary
design/change-time policy. It is simply one that includes an approval action.
An approval policy can also include other actions (assuming they are within the
policy's scope).
For more information about the approval policies, see the CentraSite online documentation section Using Approval Policies in the document Working with Design/Change-Time Policies.
To impose an approval process on an event, you include the Initiate Approval action in your policy.
This action submits a request to a designated group of approvers (referred to as the approval group). For information about using this action, see Using the Initiate Approval Action.
When a user performs an operation that triggers an approval policy, CentraSite initiates an approval workflow and submits the user's request to the designated group of approvers. Approvers receive the approval request in their in CentraSite Business user interface. Approvers whose user account includes a valid e-mail address also receive an email message informing them that a request is awaiting their approval. You can configure an approval action to send an email notification to other specified users, too.
Note:
For CentraSite to issue email messages, an administrator must first
configure CentraSite's email server settings. For procedures, see
Configuring the Email
Server.
CentraSite does not execute the user's requested operation until it obtains the necessary approvals. If an approver rejects the request, CentraSite notifies the requestor and immediately exits the policy. It does not perform the user's requested operation.
Using the in CentraSite Business user interface, users can view the status of the requests that they have submitted for approval. Approvers also use the to review and authorize requests that require their approval.
For information about reviewing requests that require your approval, see Approving a request.
When the user who submits a request is also an authorized approver for the requested operation, the request is auto-approved. (In other words, the requestor's approval is granted implicitly.)
The way in which a request is handled after it is auto-approved depends on whether the approval workflow is configured to execute in Anyone or Everyone mode.
In Anyone mode, an auto-approval completes the approval process. Such requests do not formally initiate an approval workflow, however, they do appear in the Approval History log (the log will indicate that the request was auto-approved).
In Everyone mode, the requestor's approval is registered and then the request is submitted to the remaining approvers in the approval group.
For more information about these two approval modes, see Approval Modes.
Note:
The auto-approval process also occurs when an approval action is
invoked and all of its specified approver groups are empty or all users in the
specified groups are inactive.
An approval workflow operates in one of the following modes:
Anyone
In Anyone mode, a request can be approved or rejected by any single
user in the approver group. In this mode, only one user in the group is
required to approve or reject the request. This is the default mode.
Everyone
In Everyone mode, a request must be approved by all users in the
approver group (it does not matter in which order the approvals are obtained).
A rejection by any approver in the group will cause the request to be
rejected.
You can add approval policies for the following combinations of events and object types.
| Event Type | Supported Object Types | Supported Approval Actions |
|---|---|---|
| PreStateChange | Asset | Initiate Approval Initiate Group-dependent Approval |
| OnConsumerRegistration | Asset | Initiate Approval Initiate Group-dependent Approval |
| OnTrigger | Asset | Initiate Approval |
You use the Initiate Approval action when you want to define an approval process that applies to all of the users who submit requests that trigger the policy.
The parameters required to define the action include the name of the approval flow that the action initiates, the name of the approver groups (i.e. the groups of users who are allowed to approve requests that trigger the policy), and email addresses of users who should be informed of the progress of the action.
The parameters are described in the description of the Initiate Approval action in the document Built-In Design/Change-Time Actions Reference.
When you want a policy to initiate an approval process for some groups of requestors and not for others, or when you need to route requests to different approvers based on the user group to which a requestor belongs, you use the Initiate Group-dependent Approval action.
The parameters required to define the action include the name of the approval flow that the action initiates, the name of the approver groups (i.e. the groups of users who are allowed to approve requests that trigger the policy), the names of the related triggering groups (i.e. the groups of members whose requests require approval), and email addresses of users who should be informed of the progress of the action.
The parameters are described in the description of the action Initiate Group-Dependent Approval in the document Built-In Design/Change-Time Actions Reference.
You can route approvals to different approver groups based on the triggering group to which the requestor belongs. For example, you could configure the action to route requests to the approver groups Approvers-A and Approvers-B when a requestor belongs to a particular triggering group.
Points to consider when using the Initiate Group-dependent Approval action:
If a requestor does not belong to any of the groups specified in the Triggering Groups parameter, CentraSite does not even initiate an approval workflow. Approval is waived and CentraSite simply executes the next action in the policy. (Be aware that, because the request does not enter the approval framework, requests that are waived do not appear in the Approval History log.)
The UI dialog allows you to combine triggering groups and approval groups into sets, where each set defines one or more triggering groups and the associated approver groups. You can specify multiple sets, and CentraSite processes each set in the order given in the dialog. When it encounters a set whose Triggering Groups parameter includes a user group to which the requestor belongs, it immediately initiates an approval workflow based on that set and ignores any remaining sets in the dialog. In other words, if the requestor is a member of multiple Triggering Groups, approval is determined by whichever of those groups appears first in the dialog.
If a requestor is a member of both Triggering Groups and a member of Approver Group in the same triggering group/approver group combination, the request is auto-approved.
By default, an asset's lifecycle state is not changed when an approval
request is rejected. For example, let's say that asset Approval Service is in
the "Tested" state and an approval request is
submitted to switch asset Approval Service to the
"Production" state. If the approval request is
rejected, asset Approval Service stays in the
"Tested" state. For some approval workflows,
however, you might want to switch assets to a particular state when they are
rejected. To do this you use the Reject State parameter
in CentraSite Control.
Important:
If you use this option, make sure that the lifecycle model
provides a transition from the state(s) that an asset might be in when the
approval policy executes and the state that you specify in the Reject
State parameter. Otherwise, the approval engine will not be able to
switch the target asset to the specified state when a rejection
occurs.
Also be aware that you can specify only one state in the Reject State parameter. Therefore, if an approval policy applies to assets with different lifecycle models, the Reject State can apply to only one of those models. For example, let's say you use the same approval policy for both XML schemas and services, but these two asset types follow different lifecycle models. If you set the Reject State to a state in the lifecycle model for XML schemas, only XML schemas will switch to this state when an approval request is rejected. Services, when rejected, will simply remain in their current state. If you want to specify one reject state for XML schemas and another for services, you must create a separate approval policy for each type.
To create an approval policy, you must perform the following general steps:
If one does not already exist, create a user group composed of the individuals who are authorized to approve the type of request that triggers the policy. For information about creating user groups that represent authorized approvers, see Approver Groups.
Create a design/change-time policy with the appropriate scope (event type and object type) and into this policy, insert an approval action.
For information about the event types and object types with which you can use an approval action, see What Types of Events and Objects Can Be Approved?.
For general information about creating policies, see Adding a Design/Change-Time Policy to CentraSite.
For specific information about using policies with the PreStateChange event type, see Using Approvals with PreStateChange Events.
An approval policy can include actions in addition to the approval action. For example, you might create a policy like the example shown below, which validates a particular attribute in the asset and executes a custom action before it initiates the approval process.
| Example |
|---|
Validate Attribute Value |
The example above illustrates how you can execute policy actions before you initiate the approval process. You can also insert actions after the approval action as long as those actions DO NOT attempt to modify the asset on which the policy is acting. When an asset enters an approval process, CentraSite locks the asset to prevent any modifications to the asset while it is undergoing approval. The asset remains locked until the approval policy and all additional policies that are triggered by the same event are complete.
If an approval policy includes an action that attempts to update the asset after approval process has been initiated, that action will fail. When this occurs, CentraSite immediately exits the policy and reverts the asset to its previous state.
The following shows an approval policy that includes an action after the approval action. This policy will execute successfully, because the action following the approval action simply sends out an email notification. It does not attempt to modify the asset on which the policy is acting.
| Example A (correct) |
|---|
Validate Classification |
The following shows an approval policy that would not execute successfully. In this example, the Set Instance and Profile Permissions action follows the Initiate Approval action. Because the asset is locked at this point in the policy, the Set Instance and Profile Permissions action will fail and the asset will revert to its previous lifecycle state.
| Example B (incorrect) |
|---|
Validate Classification |
Tip:
As a best practice, avoid executing any additional actions after the
approval action in an approval policy. If there are actions that you need to
execute after approval is granted, place those actions in a separate policy
that executes on the PostStateChange event.
The PreStateChange event occurs when you change the lifecycle state of an asset.
You can use an approval policy with the PreStateChange event to prevent users from switching the assets to certain lifecycle states (e.g., to the Productive state) without first getting the required approvals:
To create an approval policy that executes on a PreStateChange, you must perform the following general steps:
Make sure that the state change(s) that will trigger the policy are defined in an existing lifecycle model. If the lifecycle model, with the appropriate state, has not yet been defined, you must create it before you create the approval policy. For procedures, see the document Customizing Lifecycle Management.
Create a design/change-time policy with the following scope:
Event Type: PreStateChange
Object Type: Asset or Lifecycle Model
For procedures, see Adding a Design/Change-Time Policy to CentraSite.
In the Before the Object Enters State section of the policy's States tab, specify the state change that requires approval. For procedures, see Configuring Policies that Execute on Lifecycle State Changes.
On the policy's Actions tab, specify and configure the approval action that is to be executed when an asset switches to the state specified in the preceding step. If other actions are to be executed before or after the approval action, insert those actions on the Action tab, too. For procedures, see .
Caution:
Only certain kinds of actions can be included after the
approval action in an approval policy. Some actions, if they occur after the
approval action, will cause the policy to fail. For information about what kind
of actions can follow an approval action, see "Including Multiple Actions in an Approval
Policy".
The OnConsumerRegistration event occurs when an asset owner reviews a consumer registration request and accepts the request by clicking the "pending approval requests" in the asset's Basic Information profile.
An organization must have a consumer-registration policy to process the consumer registrations that are initiated using the menu command. At a minimum, this policy must include the Register Consumer action, because this action performs the work of actually registering a consumer (that is, it establishes the actual relationship between the asset and the specified consumers). If, in addition to the asset owner, you want designated individuals to review and approve the registration request, place an approval action before the Register Consumer action.
Note:
The approval process that is imposed by a consumer-registration
policy occurs in addition to the review and approval that is required
by the asset owner. That is, the asset owner always reviews the registration
first, and if he or she accepts the registration, the request proceeds through
the approval process defined by the consumer-registration policy.
The following procedure describes the general steps you use to create a consumer-registration policy that includes an approval action.
Create a design/change-time policy with the following scope:
Event Type: OnConsumerRegistration
Object Type: Asset (of any type)
If you need procedures for this step, see Adding a Design/Change-Time Policy to CentraSite.
On the policy's Actions tab, add the following actions. Make sure the approval action precedes the Register Consumer action.
Initiate Approval —OR— Initiate Group-dependent Approval
Register Consumer
If you need procedures for adding actions to a policy, see .
Configure the approval action's input parameters. If you need procedures for this step, see Configuring Policy Action Parameters.
Insert additional actions before and/or after this pair of actions as necessary.
The following example shows an action list that obtains the required approval, executes the registration process, and then grants instance-level permissions to the consumers that the policy registers.
| Example |
|---|
Initiate Approval |
The OnTrigger event occurs when an Organization Administrator reviews a consumer (user) registration request and accepts the request by clicking the "pending user registrations requests" in the organization's Basic Information profile.
An organization must have a consumer-onboarding policy to process the consumer registrations that are initiated using the action. At a minimum, this policy must include the Create User and Consume API actions, because these actions perform the work of actually registering a user as consumer and establishing the actual relationship between the API and the specified consumers). If, in addition to the API owner, you want designated individuals to review and approve the registration request, place an approval action before the Create User action.
Note:
The approval process that is imposed by a consumer-onboarding policy
occurs in addition to the review and approval that is required by the
Organization Administrator. That is, the Organization Administrator always
reviews the registration first, and if he or she accepts the registration, the
request proceeds through the approval process defined by the
consumer-onboarding policy.
The following procedure describes the general steps you use to create a consumer-onboarding policy that includes an approval action.
Create a design/change-time policy with the following scope:
Event Type: OnTrigger
Object Type: Asset (Service, XML Service, REST Service)
If you need procedures for this step, see Adding a Design/Change-Time Policy to CentraSite.
On the policy's Actions tab, add the following actions. Make sure the approval action precedes the Register Consumer action.
Initiate Approval —OR— Initiate Group-dependent Approval
Create User
Consume API
If you need procedures for adding actions to a policy, see .
Configure the approval action's input parameters. If you need procedures for this step, see Configuring Policy Action Parameters.
Insert additional actions before and/or after this pair of actions as necessary.
The following example shows an action list that obtains the required approval, executes the registration process, and then grants the API for consumption to the consumers that the policy registers.
| Example |
|---|
Initiate Approval |
An approver group is simply a user group that identifies the set of individual who are authorized to approve a submitted request. An approver group can be composed of users from any organization.
Note:
If you want approvers to be able to review the details for an asset
that they are asked to approve, make those users have View permission on the
asset. For example, if the users in group ABC will be required to approve
assets that are switched to a certain lifecycle state, make sure that the users
in group ABC have View permission on the assets that they will be asked to
approve. Without View permission, approvers will not be able to examine the
details of the assets that users submit to them for approval.
Changing the membership of an approver group does not affect requests that are already pending approval. When CentraSite submits a request to the approval engine, it assigns the users from the specified approver group to that request. The request retains its assigned set of approvers throughout the entire approval process.
For example, let's say that approval policy P1 uses approver group AG1, and that AG1 contains users A and B. If a user submits a request that triggers P1, users A and B will become the designated approvers for that request. Let's say that while this request is waiting for approval, an administrator modifies group AG1 and replaces users A and B with users X and Y. This change will have no effect on the request that is awaiting approval. Users A and B will continue to its designated approvers. The changes to group AG1 will only affect new requests that policy P1 submits for approval.
In the CentraSite Business UI's Inbox, CentraSite maintains a record of every request that users submit for approval. You can use the following procedure to view your requests and examine their status.
Note:
The list displays all requests that have been submitted on
your behalf, including requests that were auto-approved.
To view requests that you have submitted for approval
In CentraSite Business UI, display .
You will see the list of requests that you have submitted for approval.
To examine the details for a particular request (including a list of the individuals who are authorized to approve the request), click its hyperlinked name.
The details for the request will appear in the Approval Request dialog.
The Status in the Approval Requests dialog indicates the state of the particular request as follows:
| Status | Description |
|---|---|
| Pending | The request has been submitted for approval, but has not yet been processed by the required approvers. |
| Approved | The request has been submitted and approved by the required approvers. |
| Rejected | The request has been submitted and rejected. The operation you requested was not executed. |
| Auto-Approved | The request was auto-approved. This occurs when you submit a request for which you are also an authorized approver. |
If you are an approver, CentraSite places approve requests (i.e., any request whose approver group included you as a member) in the organization or asset details page for you to review and authorize the requests.
To view and approve requests for an asset
In CentraSite Business UI, display the details page of the asset that requires your approval. If you need procedures for this step, see the section Viewing Details for an Asset.
Locate the pending approval requests for an asset in the description area of the Basic Information profile. For example, "N number of pending approvals”.
If there are no pending approval requests for the asset, this is simply displayed as “0 ".
Choose the request that you want to review and approve by clicking its hyperlinked name.
The details for the request will appear in the Approval Request dialog
In the Comment text box, type a comment. (e.g., "Request rejected. Add required specifications to this asset and resubmit".)
Click the or button as appropriate to approve or reject the request.
Occasionally, you might need to revert a request that has been submitted for approval. For example, if a request that has already been submitted to the approval engine requires the approval of a user who has left the company, you will need to back that request out of the approval engine and resubmit it (after updating the approver group, of course).
When you have an approval request that is stuck in the "pending" mode, a user in the CentraSite Administrator role can use the following procedure to revert the object to its previous state so that the condition can be corrected and the object can be resubmitted for approval.
Note:
Reverting the lifecycle state of an asset does not undo any attribute
changes that might have been made by policies that were executed by the
original state-change event. It simply returns the asset's lifecycle property
to its previous state. If other attribute changes occurred during the
state-change event, you will need to undo those changes manually.
To revert the state of an asset that is pending approval
In CentraSite Business UI, display the asset whose pending state you want to revert. If you need procedures for this step, see the section Viewing Details for an Asset.
On the asset details page, click the (
) icon.
