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).
CentraSite provides predefined policies specific to the Business UI.
By default, predefined policies are not displayed by CentraSite Control. To view predefined policies, you must enable the Show Predefined Policies option on the Design/Change-Time Policy page.
| Policy | For more information |
|---|---|
| Creating an Account | See Using the New Account Policies. |
| Onboarding a Consumer | See Using the Consumer Onboarding Policies. |
| API Key Generation | See Using the API Key Generation Policies. |
| API Key Renewal | See Using the API Key Renewal Policies. |
| API Key Revocation | See Using the API Key Revocation Policies. |
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.
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 details page 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:
To use the email options provided by this action, CentraSite must have a connection to an SMTP email server. For instructions
on how to configure CentraSite's connection to an email server, 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.
Using the details page in CentraSite Business user interface, users can view the status of the requests that they have submitted for approval. Approvers also use the details page 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 Request 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.
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 | Service, Organization | Initiate Approval |
The New Account policies trigger an approval workflow when users request for an account in the CentraSite registry.
When users request a CentraSite account (as described in Creating Your New Account), the policy is triggered and the "User Registration" or an "Organization with User Registration" request is submitted to all members of the approval list specified in the "Initiate Approval" action. Then, the approvers can either approve or decline the request. If the approvers approve the request, the users will be registered in the CentraSite registry, and appropriate permissions will be assigned to users.
To use the CentraSite's new account feature, you must configure the "Global New User Account Policy" and every organization's "New User Account Policy".
Note:
You do not need to explicitly activate the new account
policies.
The Global New User Account Policy enables an automated user registration to address the following scenarios:
If the user does not explicitly specify an organization, the policy registers the user in the organization defined in the "Onboarding Organization" action of the policy. By default, it is set to "Default Organization".
If the user specifies an organization which does not currently exist in the CentraSite registry, the policy creates the new organization, and registers the user in the new organization.
The Global New User Account Policy has input parameters that you must set to enforce the user registration.
To configure the input parameters for Global New User Account
Policy
Display the Global New User Account Policy Details page whose actions you want to configure. If you need procedures for this step, see Viewing or Changing a Policy.
On the Actions tab do the following:
Mandatory. To configure the Initiate Approval action, set the following parameters:
Mandatory. Approver Group: Specify the designated group of approvers.
Mandatory. Approval is needed from: Specify an approval mode "All" or "Anyone".
Click Save to update the parameter settings.
For more information about configuring the Initiate Approval action, see the section Initiate Approval in the document Built-In Design/Change-Time Actions Reference.
To configure the Onboarding Organization action, set the following parameters:
Mandatory. Onboarding Organization: Specify the organization in which you want to register the user, when the requestor has not specified any organization. By default, "Default Organization".
Onboarding Success Message: Specify a notification template for the new user account success message. By default, "NewAccountSuccessMessage.html".
Click Save to update the parameter settings.
The "New User Account Policy" of an organization enables an automated registration of user for the particular organization.
The New User Account Policy has input parameters that you must set to enforce the user registration.
To configure the input parameters for New User Account Policy
Display the New User Account Policy Details page whose actions you want to configure. If you need procedures for this step, see Viewing or Changing a Policy.
On the Actions tab do the following:
On the Initiate Approval action, set the parameters:
Mandatory. Approver Group: Specify the designated group of approvers.
Mandatory. Approval is needed from: Specify an approval mode "All" or "Anyone".
Click Save to update the parameter settings.
On the Onboarding User action, set the parameters:
Onboarding Organization: Specify the organization in which you want to register the user. By default, "Default Organization".
Onboarding Success Message: Specify a notification template for the new user account success message. By default, "NewAccountSuccessMessage.html".
Click Save to update the parameter settings.
CentraSite's approval-management framework enables you to configure policies that trigger approval processes when guest users (i.e. users without a valid CentraSite user account) try to access and register as consumers of APIs.
When users request to consume APIs (as described in Registering as Consumers for an API), the policy is triggered and the "User Registration" or an "Organization with User Registration" request is submitted to all members of the approval list specified in the "Initiate Approval" action. Then, the approvers can either approve or decline the request. If the approvers approve the request, the users will be registered as consumers, and appropriate permissions will be assigned to users.
To use the CentraSite's consumer-onboarding feature, you must configure the "Global Onboarding Policy" and every organization's "User Onboarding Policy".
Note:
You do not need to explicitly activate the onboarding
policies.
The Global Onboarding Policy enables an automated onboarding to address the following scenarios:
If the user does not explicitly specify an organization, the policy onboards the user in the organization defined in the "Onboarding Organization" action of the policy. By default, it is set to "Default Organization".
If the user specifies an organization which does not currently exist in the CentraSite registry, the policy creates the new organization, and onboards the user in the new organization with an "Organization Administrator" role.
On successful onboarding of an user within the specified organization, CentraSite performs the API consumption process that has already been initiated.
The Global Onboarding Policy has input parameters that you must set to enforce the consumer onboarding.
To configure the input parameters for Global Onboarding Policy
Display the Global Onboarding Policy Details page whose actions you want to configure. If you need procedures for this step, see Viewing or Changing a Policy.
On the Actions tab do the following:
Mandatory. To configure the Initiate Approval action, set the following parameters:
Mandatory. Approver Group: Specify the designated group of approvers.
Mandatory. Approval is needed from: Specify an approval mode "All" or "Anyone".
Click Save to update the parameter settings.
For more information about configuring the Initiate Approval action, see the section Initiate Approval in the document Built-In Design/Change-Time Actions Reference.
To configure the Onboarding Organization action, set the following parameters:
Mandatory. Onboarding Organization: Specify the organization to which you want to onboard the user as a consumer, when user requesting for an account has not specified any organization. By default, "Default Organization".
Onboarding Success Message: Specify a notification template for the consumer onboarding success message. By default, "OnboardingSuccessMessage.html".
Click Save to update the parameter settings.
The "User Onboarding Policy" of an organization enables an automated onboarding of user for that organization. On successful onboarding, performs the API consumption process that has already been initiated. If the API consumption includes an approval workflow, on approval, CentraSite generates the API key. On the other hand, if the API consumption does not include an approval workflow, CentraSite generates the API key immediately.
The User Onboarding Policy has input parameters that you must set to enforce the consumer onboarding.
To configure the input parameters for User Onboarding Policy
Display the User Onboarding Policy Details page whose actions you want to configure. If you need procedures for this step, see Viewing or Changing a Policy.
On the Actions tab do the following:
On the Initiate Approval action, set the parameters:
Mandatory. Approver Group: Specify the designated group of approvers.
Mandatory. Approval is needed from: Specify an approval mode "All" or "Anyone".
Click Save to update the parameter settings.
On the Onboarding User action, set the parameters:
Onboarding Organization: Specify the organization to which you want to onboard the user as consumer. By default, "Default Organization".
Onboarding Success Message: Specify a notification template for the consumer onboarding success message. By default, "OnboardingSuccessMessage.html".
Click Save to update the parameter settings.
placeholder
placeholder
The following actions are typically used with the API Key Generation policy.
Approval
Renew
Audit Log
Deploy
Email Notification
placeholder
If selected (require approval), a configuration similar to key generation would be shown, where provider can configure the approver group/approval from/email notifications.
If unselected (auto approval), a empty group would be used for policy to switch to auto approval mode.
Once the renewal request is approved by approver group, consumer would be intimated by mail using "Approved" email configuration in approval policy action.
Policy action which can extend the expiration date by given expiration interval. Basically this action reads the api key being processed from context of the policy being run, and extend the expiration interval using SOALink API's(ApiKey). This action must be run by provider(who is the owner of the API Key).
expiration interval (xs:string)
Writes a audit entry for extending the expiration date. Since policy is run by provider, owner of this audit event would be provider. audit message given in the parameter would be a comment for the audit event.
audit message
Action helps to redeploy the updated API key instance to runtime target. This action would push the updated API key into all the targets associated with the API.
Note:
The action is prone to failure due to the fact that mediator may be
down/unreachable. In case of failure, provider would be intimated via mail(if
configured). Lets say if the api Key is already deployed in 5 targets and after
key renewal, re deployment failed in 2 targets, a single mail would be sent to
provider indicating key deployment failed in the failed targets. At the moment
provider can not deploy a api key alone. He has to redeploy the api to deploy
the updated key (after taking corrective actions in mediator).
placeholder
Consumer can perform API Key Revoke operation from User Preference Page. To configure the Revoke operation we need ship a predefined policy template in CentraSite. Moreover, we need to create a policy template to register the Audit log of the revoke operation.
The policy instance will be created during API Key settings configuration. The policy would have action instance like Revoke API Key, Audit Log, and Email Notification for Consumer and Provider. The policy will be triggered from the Privilege Service.
The following actions are typically used with the API Key Renewal policy.
Approval
Renew
Audit Log
Deploy
Email Notification
On-Trigger
API Key
placeholder
placeholder
placeholder
placeholder
placeholder
Consumer can perform API Key Revoke operation from User Preference Page. To configure the Revoke operation we need ship a predefined policy template in CentraSite. Moreover, we need to create a policy template to register the Audit log of the revoke operation.
The policy instance will be created during API Key settings configuration. The policy would have action instance like Revoke API Key, Audit Log, and Email Notification for Consumer and Provider. The policy will be triggered from the Privilege Service.
The following actions are typically used with the API Key Revocation policy.
Approval
Renew
Audit Log
Deploy
Email Notification
On-Trigger
API Key
Policy action which can extend the expiration date by given expiration interval. Basically this action reads the api key being processed from context of the policy being run, and extend the expiration interval using SOALink API's(ApiKey). This action must be run by provider(who is the owner of the API Key).
expiration interval (xs:string)
Writes a audit entry for extending the expiration date. Since policy is run by provider, owner of this audit event would be provider. audit message given in the parameter would be a comment for the audit event.
audit message
placeholder
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, Organization)
If you need procedures for this step, see Adding a Design/Change-Time Policy to CentraSite.
On the policy's Actions tab, do one of the following.
Note:
Make sure the approval action precedes the
operation-specific actions.
If the object type "Organization" is selected, choose the following actions.
Initiate Approval
Onboarding Organization —OR— Onboarding User
If the object type "Service" is selected, choose the following actions.
Initiate Approval
Onboarding Organization —OR— Onboarding User
Onboarding 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.
