Skip Headers
Oracle® Fusion Middleware User's Guide for Oracle Identity Manager
11g Release 2 (11.1.2)

Part Number E27151-04
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

9 Managing Requests

In Oracle Identity Manager, various operations, such as adding a role to self or provisioning an application instance, is performed through requests. A request is an entity created by the users or administrators performing a specific action that requires a discretionary permission to be gained by someone or some process before the action can be performed. For example, a user can create a request to gain access to a laptop computer, and a manager can create an open requisition based on the request.

A request has a requester, a beneficiary (optional), and a target entity. A requester is an entity that creates or raises a request. A requester can be a user or the system itself. The functional component decides on the requester for system-generated requests. An example of a system-generated request is a request created by the system based on access policy. Here, the functional component is access policy. For unauthenticated requests, the requester is not authenticated to Oracle Identity Manager and is therefore, not present in the system.

A beneficiary is an entity that benefits from the action performed after the request is completed and the request is completed only if it is executed successfully.

In Oracle Identity Manager, terms such as role, application instance, and entitlements are defined as entities. Each one of these entities maintains a list of attributes belonging to this entity. Each entity also defines a list of operations that it supports.

Target entity is the resource or entity that is requested for the beneficiary.

For instance, you create a request to provision a UNIX account for the user John Doe. Here, you are the requester, John Doe is the beneficiary, and the UNIX account is the target entity that is requested for John Doe.

As discussed earlier in this guide, Oracle Identity Manager supports requesting for entities such as users, resources, roles, application instances, and entitlements. You can request for these entities by using a request catalog.

Each request goes through a specific lifecycle after it is created in the system. This lifecycle is managed and controlled by the Request Service. The lifecycle transitions the request through various stages. The stage that a request is in determines what action the controller takes in that step, what operations are available on the request, and what possible stage the transitions are in at that time. Figure 9-1 outlines the process flow of a request:

Figure 9-1 Request Process Flow

Description of Figure 9-1 follows
Description of "Figure 9-1 Request Process Flow"

The request process flow is described with the help of an example of provisioning a laptop computer to a user through a request. The steps are:

  1. The requester raises a request to assign a laptop computer to a user by using the Request UI.

    Note:

    Requests can be raised by using Oracle Identity Self Service or Oracle Identity System Administration.

  2. The request is submitted to the request service.

  3. The request is also stored in Oracle Identity Manager database.

  4. Request-Level Approval workflow is initiated by request service in Service-Oriented Architecture (SOA). Based on the workflow configuration, associated tasks are assigned to the corresponding approvers.

    See Also:

    "Developing Workflows for Approval and Manual Provisioning" for information about approval workflows in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager

  5. The request-level approver approves the request by using the Pending Approvals page in Identity Self Service. In this example, the requester's manager (Approver 1) is the request-level approver who decides whether to assign a laptop to user 1. If the request-level approver rejects the request, the request goes to a Rejected stage.

    Note:

    When a user requests for an item, Oracle Identity Manager checks if the requester can view the catalog items, but does not check if the items can be granted to the beneficiary. When the request is approved, then Oracle Identity Manager checks if the requested access can be granted to the beneficiary.

  6. If the Approver1 has designated his role to Approver 2 then Approver 2 is the request-level approver who decides whether to assign a laptop to user 1. If Approver 2 rejects the request, the request goes to a Rejected stage.

  7. The operation-level approver approves the request by using the Pending Approvals page. In this example, the IT admin for the organization is the operation-level approver (Approver 2) who is responsible for issuing a laptop to the user. If the operation-level approver rejects the request, then the request goes to a Rejected stage.

    Note:

    Operation-level request is not initiated if the request is rejected at the request level.

  8. The request operation is initiated in the request service, and the request is executed.

  9. The request operation is completed. At this stage, the request operation has the Completed status.

  10. The request status is updated in Oracle Identity Manager database.

This chapter describes request management in the following sections:

9.1 Request Stages

Each request goes through a specific lifecycle after it is created in the system. This lifecycle is managed and controlled by the request service. The lifecycle transits the request through various stages. The stage a request is in determines what action the controller takes in that step, what operations are available on the request at that time, and what the possible stage transitions are. Figure 9-2 outlines the lifecycle flow of a request in the request service:

Figure 9-2 Request Stages

Description of Figure 9-2 follows
Description of "Figure 9-2 Request Stages"

Note:

If a request is not submitted successfully, then the error messages are displayed in the UI. For SPML-initiated requests, the error messages are thrown to SPML.

Figure 9-2 shows all the stages that a request can go through. This diagram specifies stages for a simple request. For information about bulk request, refer to Figure 9-3, "Bulk Request and Child Request Stages".

Each stage represents the logical next step in the request lifecycle. Only the successful execution of an operation can take the request from one stage to the next.

Table 9-1 describes how a request functions at various stages through its life cycle and how a request attains these stages:

Table 9-1 Request Stages

Request Stage Description

Request Created

After successful submission of the request, the request moves to the Request Created stage.

Obtaining Approval

After the request is created, the request engine moves the request to "Obtaining Approval" stage automatically if there are approvals defined for this request. At this stage, the corresponding approvals are initiated through the request service. Upon completion of the same, the request engine looks at the model defined for this request to find out the approval selection methodology to find out the exact approval process to instantiate.

When the request engine finds out the approvals that are required to be initiated, it again calls request service to instantiate the workflow.

If a request is withdrawn or closed at this stage, then the request engine calls cancel workflow on each workflow instance. Notifications are sent to approvers about the withdrawn tasks.

Note: Configuration of notification can be done in the human task of a SOA composite.

The following request statuses are associated with Obtaining Approval stage:

  • Obtaining Request Approval

  • Obtaining Operation Approval

For information about these request statuses, refer "Bulk Requests and Child Requests".

After the request successfully completes these statuses, it will attain the Request Approved stage.

If an SoD validation check is plugged-in after the request has been successfully created, the request is associated with the following statuses.

  • SoD check not initiated

    A request attains this stage, if the SoD validation is not initiated for provisioning resource based request. The request engine moves the request to this stage after submission of request and before Obtaining Approval.

  • SoD check initiated

    A request attains this stage, if the SoD validation is initiated asynchronously for provisioning resource based request. The request engine moves the request to this stage after submission of request and before Obtaining Approval.

  • SoD check completed

    A request attains this stage, if the SoD validation is completed for provisioning resource based request. The request engine moves the request to this stage after submission of request and before Obtaining Approval.

Note: These SoD request statuses are possible in case the request is any of the following request types:

  • Provision Application Instance

  • Modify Account

  • Provision Entitlement

  • Revoke Entitlement

  • Assign Roles

  • Remove from Roles

Approved

Only after an Operation Approval is approved, the request is moved to the next stage and the request engine is updated with the current status. The outcome that the request engine finds is Approved, Rejected, or Pending.

The following request statuses are associated with this stage:

  • Request Approval Approved

  • Operation Approval Approved

Rejected

Each time a workflow instance is updated, request service updates the request engine with the current status of that instance. The outcome that the request engine expects from request service is Approved or Rejected. If any of the workflow instances that are instantiated are rejected, then request engine moves the request to Rejected stage. If any workflow instance is rejected, then the controller calls cancel on all the pending workflows and moves the request to Rejected stage.

The following request statuses are associated with this stage:

  • Request Approval Rejected

  • Operation Approval Rejected

Operation Initiated

After the request is approved, the request engine moves the request to the Operation Initiated stage and initiates the operation.

The following request statuses are associated with this stage:

  • Operation Completed

    After completing the actual requested operation, the request engine moves the request to the Operation Completed stage. This happens after Operation Initiated status and is associated with Completed stage.

  • Post Operation Processing Initiated

    After the actual requested operation is completed, if there exists any additional operation that needs to be executed as post-processing, the request engine moves the request to the Post Operation Processing Initiated stage, before initiating those operations. This happens after Operation Completed status.

Note: In case of a bulk operation, child requests are created after request level approval, and the parent request moves to the "Request Awaiting Child Requests Completion" status.

Request Failed

When the associated operations specified in the request fails to execute, the request cancels any pending operations and moves the request to the Request Failed stage.

The following request statuses are associated with this stage:

  • Request Failed

    When all associated operations specified in a request fail, the request is moved to the Request Failed stage.

  • Request Partially Failed

    When any associated operation specified in a request fails, the request is moved to the Request Partially Failed stage.

  • Request Fulfillment Failed

    When a request associated with an application instance or entitlement fails, then the request moves to the Request Fulfillment Failed stage.

  • Request Fulfillment Failed After Max Retry

    When a request associated with an application instance or entitlement that is in the Rejected stage is retried until the maximum number of retries is reached, then request moves to the Request Fulfillment Failed After Max Retry.

Withdrawn

A request can be withdrawn by the requester. At this stage, the request is associated to the Request Withdrawn status, and the initiation of all approvals are canceled.

Note:

  • A request can be withdrawn before Operation Initiated stage. Once the request attains the Operation Initiated stage, the request cannot be withdrawn.

  • A request can always be withdrawn by a requester only, which is done by using Identity Self Service.

Completed

After the execution of all operations specified in the request are completed, the request engine moves the request to the Request Completed stage.

The following request statuses are associated with this stage:

  • Request Completed with Errors

    A request attains this status, when an actual requested operation executes fine, but fails to execute any of the post-processing operations. The Request Completed with Errors stage is associated with the Failed stage.

  • Request Completed

    A request attains this status, when an actual requested operation executes fine without any errors.

  • Request Awaiting Completion

    When a request is scheduled to be executed on a future date, the request attains Request Awaiting Completion status till the operation is completed on an effective date.


The successful attainment of a stage also results in the status of the request being updated to the corresponding status.

Operations can be executed manually or automatically by the system in response to an event. Examples of manual operations are:

Examples of automatic operations are:

9.2 Bulk Requests and Child Requests

A bulk request is a request with multiple beneficiaries, multiple entities, or both. For example, a request to assign multiple roles to user John Doe generates a bulk request. Provisioning requests to provision a resource, such as AD User, to users John Doe and Jane Doe also generates a bulk request. A bulk request has two parts:

The entity data in bulk requests must be same for different beneficiaries specified in the request. For example, for a "provision application instance" type of request, if multiple beneficiaries are selected, then the form data provided for an application instance is the same and applicable for all the selected beneficiaries.

The number of child requests generated depends on the number of target entities associated with each beneficiary. For each beneficiary, one of its associated target entities is used to generate for each child request. A child request contains only one beneficiary and one target entity.

For a request with no beneficiaries, each child request is spawned for each target entity. Consider the following example:

For a modify-user bulk request that modifies the attributes of two users, two child requests are created (one for each user).

Consider another example. For a "provision application instance" type of request, there are two beneficiaries. Two application instances are to be provisioned for each beneficiary. In this scenario, there are two child requests for the first beneficiary and two child requests for the second beneficiary. Each application instance and its associated beneficiary are present in each child request. Therefore, for this bulk request, there are a total of one parent request and four child requests.

Request-level approval is performed as a part of parent request. After the parent request spawns child requests, the parent request goes to the Request Awaiting Child Requests Completion stage, where in the request awaits for the child requests to complete the operation-level approval. After all the child requests complete, the parent request moves to the Completed stage.

Operation-level approval is performed for child requests only. Approvers can approve or reject child requests individually. If all the child requests are approved or rejected, then the parent request attains the Completed stage. If one or more (but not all) of the child requests fail, then the parent request attains the Request Partially Failed stage. If all the child requests fail, the parent request attains the Failed stage.

Figure 9-3 outlines the lifecycle flow of a request in the request service:

Figure 9-3 Bulk Request and Child Request Stages

Description of Figure 9-3 follows
Description of "Figure 9-3 Bulk Request and Child Request Stages"

See Also:

Table 9-1, "Request Stages" for information about request stages

9.3 Heterogeneous Requests

Heterogeneous request is a request created for entities of different types. Oracle Identity Manager supports requesting roles, application instances, and entitlements in a single request, which is heterogeneous in nature.

The following request types are supported in a heterogeneous request:

For a request that is submitted for different entities, the request type is set as "Heterogeneous request". For example, if you submit a single request for two separate entities such as roles and entitlements, then the request type is "Heterogeneous request".

For a request that is submitted for multiple entities of same type, the request type is set according to the entity selected. For example, if you submit a request for multiple roles, then the request type is "Assign Roles".

9.4 Request vs. Direct Operation

Users in Oracle Identity Manager can perform various operations in the application. Any operation that you can perform in Oracle Identity Manager is controlled by the authorization policies that have been defined. The admin roles granted to a user in an organization determine whether an operation that a user can perform in Oracle Identity Manager happens directly or through a request. For example, if you are a user administrator, then all operations such as create user, modify user, grant account, enable user account, and so on are direct operations. Similarly, if you have been assigned the Role Viewer admin role, then operations such as create user, enable user, delete user, grant role, revoke entitlements, and so on result in a request being created. For more information about admin roles in Oracle Identity Manager, the corresponding permissions allowed to users of that admin role and whether the operation is direct or results in a request, see the "Security Architecture" chapter in Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.

Whether an operation results in a request or is performed directly depends on:

All operations in Oracle Identity Manager do not go through the authorization check to determine if it is a direct operation or a request. Determining whether an operation is a request or not will be done only for requestable operations. See the tables in "Request Categories" for information about default requestable operations.

The check for direct operation or request is applicable to an operation only if it has a corresponding request model. As a result, this authorization check is performed for creating a user, but not for creating an organization because there is no request model for creating an organization. Similarly, locking and unlocking user accounts are also operations that do not go through the authorization check to determine request or direct operation. Therefore, these operations are direct.

Note that creation of a request does not always mean that the SOA workflow is invoked and manual approval is obtained. There are scenarios in which a request is created, but approval is not required. Consider the following sample scenarios:

Scenario 1:

A request is created when the operation is bulk, but at the operational level, if the requester is determined to be the admin of the entity, then it is considered auto-approved.

Scenario 2:

If an SoD check is enabled, then the approval workflow has to be initiated always. This is because SoD check happens in the approval workflow only.

End users can submit request for entities such as application instances, entitlements, and roles published to home organization for self or others in the same organization. To submit requests for users in other organizations, you must be granted the User Viewer admin role (in each of the organizations to which the users belong), and the corresponding Application Instance Viewer, Entitlement Viewer, or Role Viewer roles.

9.5 Request Categories

There are two categories of request in Oracle Identity Manager:

9.6 Common Reasons for Request Failure

When the associated operations specified in a request fail to execute, the request cancels any pending operations and moves the request to the Request Failed stage. Clicking the Request Failed hyperlink displays the reason for request failure.

A request can fail for any one of the following reasons:

In addition to the preceding reasons, failures can occur because of incorrect password, password policy violation, target system being unavailable, and so on.

9.7 Request Profiles

When you select catalog items for requesting, the items are added to a request cart. The request cart is similar to the shopping cart in Web sites that sell products to customers. You can view the selected items in the cart, or edit the request cart to add or remove items.

Request profiles are request carts that are saved for future reuse by the users. The request cart is saved by the catalog administrator or system administrator so that the user can use it to request for entities without searching through thousands of catalog items.

Note:

When a user creates a request through request profile, the items are filtered based on authorization policies. This means that the items for which the user does not have the required privileges to request, are automatically removed from the cart. If the user is not authorized to request any item in the profile, then the cart items will be empty.

This section discusses the following topics:

Note:

Creating, modifying, or deleting a request profile can be performed only by catalog administrators or system administrators.

9.7.1 Creating a Request Profile

To create a request profile:

  1. In the Catalog page, select one or more catalog items, and click Add to Cart. The catalog items are added to the request cart.

  2. Click Checkout. The Cart Details page is displayed. The select catalog items are displayed in the Cart Items section.

  3. Click Save As Profile. The Request Cart dialog box is displayed with the catalog items in the request profile.

  4. In the Save Profile Name field, enter a name for the request profile.

  5. In the Description field, enter a description of the request profile.

  6. Click Save. The request profile is created.

9.7.2 Modifying a Request Profile

To modify a request profile:

  1. In the Request Profiles section of the Catalog page, click the request profile that you want to modify. The Cart details page is displayed.

  2. In the Cart Items section, select a cart item to display the details of the item.

  3. In the Details section, modify the request details, if required. To do so, set or modify values in the Details section, and then click Ready to Submit.

  4. If you want to add more items to the cart, then:

    1. Click Back to Catalog.

    2. On the Catalog page, search for and select items to be added to the cart, and the click Add to Cart.

  5. Click Checkout. The Cart Details page is displayed.

  6. Click Save As Profile. The Save as Profile dialog box is displayed.

  7. In the Save Profile Name field, enter the name for the request profile that is being modified. If you enter a new name, then a new request profile is created. If you enter the name of an existing request profile, then that request profile is updated with the latest changes.

  8. In the Description field, enter a description of the request profile.

  9. Click Save. Depending on whether you have entered the name of an existing request profile or new name, the request profile is created or updated, respectively.

Note:

Values that you add or specify for Target Users, Justification, or Effective Date will not saved in a request profile.

9.7.3 Deleting a Request Profile

To delete a request profile:

  1. In the Request Profiles section of the Catalog page, click the red cross mark preceding the name of the request profile.

  2. In the Confirmation dialog box that is displayed, click Yes.

    The request profile is deleted.

9.8 Creating Requests

This section describes how to create requests in the following topics:

9.8.1 Creating a Request to Register Yourself in Oracle Identity Manager

Using the login page of Identity Self Service, you can create a request to register yourself in Oracle Identity Manager. This is called a self-registration request and can be raised by users not present in Oracle Identity Manager (anonymous users). To create a self-registration request, see "Submitting Registration Requests". After submitting the self-registration request, you can track it by navigating to the login page, and clicking Track My Registration.

9.8.2 Creating a Request By Using the Request Catalog

Note:

The procedure discussed in this section is applicable for requesting roles, entitlements, and application instances.

In Identity Self Service, you can create requests from various pages, such as the Home page, My Access page, and the entity detail pages for users and roles. Irrespective of the page or tab from where you are creating the request, you go through the request catalog to create requests.

To create a request by using the request catalog:

  1. Log in to Identity Self Service.

  2. Under Requests, click Catalog. The Catalog page is displayed.

  3. Search for the item that you want to request. To do so, enter a keyword in the search field, and click the search icon on the right. The search results are displayed. The catalog items that match the search condition are listed in the Catalog Items section, as shown in Figure 9-4:

    Figure 9-4 The Catalog Page

    Description of Figure 9-4 follows
    Description of "Figure 9-4 The Catalog Page"

  4. In the Refine Search section, select one or more categories to display the catalog items of those categories. You can click Select All to display or hide all the items belonging to the categories.

  5. Select a catalog item that you want to request. The summary information of the item is displayed below the Catalog Items section.

    You can also select multiple items by pressing Ctrl and clicking the items.

  6. Click Add Selected to Cart.

    The selected items are added to the request cart.

  7. Optionally, click Edit to view the catalog items added to the cart. The Request Cart dialog box is displayed with a list of catalog items in the cart, as shown in Figure 9-5:

    Figure 9-5 The Request Cart

    Description of Figure 9-5 follows
    Description of "Figure 9-5 The Request Cart"

  8. If required, select a catalog item to display detailed information about the item. Review the details, and if required, you can remove the item from the cart by clicking Remove for the corresponding item.

    Alternatively, click Remove All to delete all items from the cart.

  9. Click Checkout. Alternatively, you can click Checkout on the Catalog page.

    The Cart Details page is displayed, as shown in Figure 9-6:

    Figure 9-6 The Cart Details Page

    Description of Figure 9-6 follows
    Description of "Figure 9-6 The Cart Details Page"

  10. The Target Users section displays the usernames of beneficiaries for the request. You can click User Details for a user to view the details of the user.

  11. To add beneficiaries to the request:

    1. Click the green plus symbol. The Advanced Search for Target Users dialog box is displayed.

    2. Search and select one or more users that you want to add.

    3. Click Add Selected to add the selected users to the Selected Users list. Alternatively, click Add All to add all the users in the Selected Users list.

    4. Click Add. The selected users or beneficiaries are added to the Target Users section of the Request Cart Details page.

    You can also select a user that you want to remove from the list of beneficiaries, and click Remove.

  12. If required, in the Justification and Effective Date section, in the respective fields, specify a justification and effective date when the request will be active.

  13. In the Cart Items section, if required, select a cart item and click Details to display the details of the item.

  14. After reviewing and modifying the details or each item in the cart, click Submit.

    The request is submitted for approval, and the Request Summary page is displayed with summary information, target user or beneficiary information, and request and approval details. Figure 9-7 shows the Request Summary page:

    Figure 9-7 The Request Summary Page

    Description of Figure 9-7 follows
    Description of "Figure 9-7 The Request Summary Page"

Note:

In the Request Summary page, if you want to withdraw the request, then click Withdraw Request, and click Yes to confirm. To withdraw requests from other pages in Identity Self Service, see "Withdrawing a Request".

9.8.3 Creating a Request By Using a Request Profile

To create a request by using the request profile:

  1. In Identity Self Service, under Requests, click Catalog. The Catalog page is displayed with the request profiles created for you.

  2. Click the request profile name that you want to use to create the request. The Cart Details page is displayed.

  3. The Target Users section displays the usernames of beneficiaries for the request. You can click information icon against each user to view the details.

  4. To add beneficiaries to the request:

    1. Click the Add icon. The Advanced Search for Target Users dialog box is displayed.

    2. Search and select one or more users that you want to add.

    3. Click Add Selected to add the selected users to the Selected Users list. Alternatively, click Add All to add all the users in the Selected Users list.

    4. Click Add. The selected users or beneficiaries are added to the Users section of the Request Cart Details page.

    You can also select a user that you want to remove from the list of beneficiaries, and click the Remove icon.

  5. If required, in the Justification and Effective Date section, in the respective fields, specify a justification and effective date when the request will be active.

  6. In the Cart Items section, select a cart item to display the details of the item.

  7. After reviewing and modifying the details or each request in the cart, click Submit.

    The request is submitted for approval, and the Request Summary page is displayed with summary information, target user or beneficiary information, and request and approval details.

9.9 Tracking a Request

To track a request:

  1. In Identity Self Service, under Requests, click Track Requests. The Track Requests page is displayed.

  2. Search for the requests you want to track. To do so:

    1. Select any one of the following:

      • All: On selecting this option, the search is performed with the AND condition. This means that the search operation returns requests that match all the search criteria that is specified.

      • Any: On selecting this option, the search is performed with the OR condition. This means that the search operation returns requests that match the search criterion that is specified.

    2. In the searchable request attribute fields, such as Request ID, specify a value. You can include wildcard characters (*) in the attribute value.

      For some attributes, select the attribute value from the lookup. For example, to search all requests with the Obtaining Operation Approval status, from the Status list, select the Equals search operator, and the select Obtaining Operation Approval from the adjacent list.

    3. For each attribute value that you specify, select a search operator from the list. The following search operators are available:

      • Starts with

      • Ends with

      • Equals

      • Does not equal

      • Contains

      • Does not contain

      For fields of date type, the search operators are:

      • Equals

      • Does not equal

      • Before

      • After

      • On or before

      • On or after

    4. To add a searchable request attribute to the Track Requests page, click Add Fields, and select the attribute from the list of attributes.

      For example, if you want to track all requests by a requester, then you can add the Requester attribute as a searchable field and specify a search condition.

    5. Optionally, click Reset to reset the search conditions that you specified. Typically, you perform this step to remove the specified search conditions and specify a new search condition.

    6. Click Search. The search results is displayed in a tabular format.

  3. If the request search you performed displays a large number of records, then you can filter the request search result. To do so:

    1. From the Show list, select any of the following:

      • Requests Raised By Me: This is selected by default. Returns requests created by logged-in user.

      • Requests Raised For Me: Returns requests where login user exists as beneficiary or target user.

      • For Reportee: This option is available if the logged-in user is a manager of a user.

      • For User: This option is available if the logged-in user has been granted the User Administrator or the HelpDesk admin role.

      • All: Returns all requests in the search result. This option is available if the logged-in user has been granted the System Administrator role.

    2. To sort the requests in the search result by any of the columns such as Request ID or Status, click the Sort Ascending or Sort Descending arrows in the column. The requests in the search result are sorted by the selected column.

  4. In the request search result, click a request to view the details of the request. The details of the request is shown in a page with the following information:

    • Summary information: This section shows general request details, such as request ID, request status, and effective date.

    • Target Users: This section lists the beneficiaries or target users for the request.

    • Related Requests: This section lists requests that are related to the open request, if any.

    • Request Details: This tab lists the requested catalog items. You can select an item to display a summary information of the item.

    • Approval Details: This tab displays the status of request approval by each approver to whom the request has been assigned.

9.10 Withdrawing a Request

A request can be withdrawn by the requester and only the requests that have not started the execution phase can be withdrawn. Also, beneficiaries cannot withdraw requests. Requests having the following stages can be withdrawn:

To withdraw a request:

  1. In Identity Self Service, under Requests, click Track Requests. The Track Requests page is displayed.

  2. Search for the requests that you want to withdraw. The search results display a list of requests that match your search criteria with a Withdraw Request button for each request.

  3. For a request that you want to withdraw, click Withdraw Request. Alternatively, you can open the details of a request by clicking the request ID, and subsequently clicking Withdraw Request on the request details page.

  4. Click Yes in the confirmation message box. The request is withdrawn and a notification is sent to the beneficiary and requester of the request. If the withdrawal is successful, then request moves to the Request Withdrawn stage. Any pending approval tasks associated with the request are canceled.

    Note:

    • Configuration of notification can be done in the human task of a SOA composite.

    • For more information about request-related tasks, such as approving a request, reassigning a task, and rejecting a task, see "Managing Tasks".

9.11 Closing a Request

Administrators can prematurely close any request that has not started the execution phase. This includes all requests waiting for approvals or has completed approvals but no operation has been started. Requests with the following state can be closed:

Note:

  • The requester or the beneficiary of a request cannot close the request.

  • If a request is closed while the request is in the Obtaining Approval stage, then all the approvals that are still pending in the approver task list are removed.

To close a request:

  1. In Identity Self Service, under Requests, click Track Requests. The Track Request page is displayed.

  2. Search for the requests that you want to close. The requests that match the search condition are displayed in a tabular format.

  3. Select the request that you want to close.

  4. From the Actions menu, select Close Request. Alternatively, you can click the Close Request icon on the toolbar.

  5. Click Yes in the confirmation message box. The request is closed and a notification is sent to the requestor and target user of this request. When a request is closed successfully, the request moves to the Request Closed stage.

    Note:

    • Configuration of notification can be done in the human task of a SOA composite.

    • For more information about request-related tasks, such as approving a request, reassigning a task, and rejecting a task, see "Managing Tasks".