This document covers the following topics:
CentraSite's approval-management framework enables you to create polices that trigger approval processes when certain time events occur in the registry. For example, you might create a policy that requires 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).
Note:
The use of approval policies is not supported if you are using a
CentraSite Community Edition license.
CentraSite provides the following actions for obtaining approvals. To impose an approval process on an event, you include one of these actions in your policy.
| Action Name | Description |
|---|---|
| Initiate Approval | 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. |
| Initiate Group-dependent Approval | This action submits a request to the approval group only if the requestor belongs to a specified user group. For information about using this action, see Using the Initiate Group-dependent 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 "inbox" in CentraSite Control. 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 the section
Configuring the Email Server in the document Basic
Operations.
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 nor does it execute any remaining actions in the approval policy. If other policies were to be executed against the user's request (i.e., if the request triggered lower priority policies in addition to the approval policy) those policies are not executed.
Using the Inbox on the My CentraSite page in CentraSite Control, users can view the status of the requests that they have submitted for approval. Approvers also use the Inbox to review and authorize requests that require their approval.
For information about checking the status of requests that you have submitted for approval, see Reviewing Requests that You Have Submitted for 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.
You configure an approval action to operate 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 Policy |
Initiate Approval Initiate Group-dependent Approval |
| OnConsumerRegistration | Asset | Initiate Approval Initiate Group-dependent 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. If you need to apply the approval process selectively, that is, if only certain groups of users require approval, or if different groups of users require authorization from different groups of approvers, use the Initiate Group-dependent Approval action instead.
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 object's lifecycle state is not changed when an approval request is rejected. For example, let's say that object ABC is in the "Tested" state and an approval request is submitted to switch object ABC to the "Production" state. If the approval request is rejected, object ABC stays in the "Tested" state. For some approval workflows, however, you might want to switch objects to a particular state when they are rejected. To do this you use the Reject State parameter.
Important:
If you use this option, make sure that the lifecycle model
provides a transition from the state(s) that an object 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 object 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 objects 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 object on which the policy is acting. When an object enters an approval process, CentraSite locks the object to prevent any modifications to the object while it is undergoing approval. The object 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 object after approval process has been initiated, that action will fail. When this occurs, CentraSite immediately exits the policy and reverts the object 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 object.
You can use an approval policy with the PreStateChange event to prevent users from switching the following types of objects to certain lifecycle states (e.g., to the Productive state) without first getting the required approvals:
Policy
Asset
Lifecycle model
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: Policy, 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 in-scope object 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 Assigning Actions to a Design/Change-Time Policy.
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 button in the Pending Registrations view on the My CentraSite page.
Note:
Because asset owners are not required to review consumer
registrations that are initiated from an asset's Consumers
profile, an approval policy that executes OnConsumerRegistration is not
triggered when a consumer is registered in this manner. The only kinds of
consumer registrations that are subject to an approval policy are those that
are initiated using the menu
command.
As described in the section Consumer Provisioning and Consumer-Provider Relationship Tracking in the document Working with Consumer Applications, 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 Assigning Actions to a Design/Change-Time Policy.
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 |
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 object
that they are asked to approve, make those users have View permission on the
object. 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 Approval History log, 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 Control, go to > My CentraSite to display the My CentraSite page.
Click Menu > Inbox > Approvals > Approval Requests to display the list of requests that you have submitted for approval.
The Status column in the Approval Requests list indicates the state of each 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. |
To examine the details for a particular request ( including a list of the individuals who are authorized to approve the request), click any "non-linked" area in the row that contains the request. CentraSite Control
The details for the request will appear in the Approval Flow Information panel.
If you are an approver, CentraSite places requests in your Pending Approvals inbox for your review and approval.
To view and approve requests in your inbox
In CentraSite Control, go to > My CentraSite to display the My CentraSite page.
Click Menu > Inbox > Approvals > Pending Approvals to display the list of requests that require your approval.
Choose the request that you want to review by clicking any "non-linked" area within the row that contains the request.
Note:
If you want to examine the object on which the approval is
requested, click the object name in the Approval Request
column. If you have View permissions on the object, you will be allowed to view
the object's details.
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.
The Approval History link in your inbox displays all requests for which you were an authorized approver (i.e., the list includes any request whose approver group included you as a member).
To view your approval history
In CentraSite Control, go to > My CentraSite to display the My CentraSite page.
Click Menu > Inbox > Approvals > Approval History to display the list of requests for which you were an authorized approver.
To examine the details for a particular request, including the list of other authorized approvers, choose the approval workflow in the Approval Request column.
Use the following procedure to display the Approval History log. This log contains a record of all approval requests that have been submitted to CentraSite. To view the Approval History log, you must belong to a role that has the "View Approval History" permission. If you belong to the CentraSite Administrator role, you will see all entries in the Approval History log. Otherwise, you will see only the set of approval requests that were triggered within your organization.
For additional information about the approval log, see the document Logging.
To view the Approval History log
In CentraSite Control, go to > > .
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 simple 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 object that is pending approval
In CentraSite Control, use one of the following steps to display the list that contains the object whose pending state you want to revert.
| To revert the state of this type of object... | Do this in CentraSite Control,.. |
|---|---|
| Asset | Go to > . |
| Design/Change-Time Policy | Go to > . |
| Run-Time Policy | Go to > . |
| Lifecycle Model | Go to > > . |
Locate the object whose state you want to revert and choose from its context menu.
Note:
For assets, you can also perform the command from the menu on the
asset detail page.
CentraSite provides a Web service that enables you to create applications and/or integrate third-party workflow tools with CentraSite's approval queue. This service provides operations that enable you to obtain the list of pending requests for an approver and approve or reject those requests via a Web service. The Web service also provides operations for viewing the approval history log.
For more information about using the Approval service, see the section Approval Service in the document CentraSite Web Service Interfaces.
