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

Part Number E14316-08
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

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

10 Managing Requests

In Oracle Identity Manager, various operations, such as creating a user or provisioning a resource, can be 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 user, organization, roles, and resources 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 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.

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 10-1 outlines the process flow of a request:

Figure 10-1 Request Process Flow

Description of Figure 10-1 follows
Description of "Figure 10-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 Manager Self Service or Oracle Identity Manager Identity Administration.

  2. The request is submitted to the request service.

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

  4. Template-Level Approval workflow is initiated by request service in Service-Oriented Architecture (SOA).

  5. If the template has approval process, then approval workflow at the template level gets initiated. If the template has no approval process, then the request gets auto approved.

  6. 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:

    "Approval Workflows" for information about approval levels and approval workflows in the Oracle identity Manager Developer's Guide

  7. The request-level approver approves the request by using the TaskList in Oracle Identity Manager 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.

  8. 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.

  9. The operation-level approver approves the request by using the TaskList. 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.

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

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

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

This chapter describes request management in the following sections:

10.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 10-2 outlines the lifecycle flow of a request in the request service:

Figure 10-2 Request Stages

Description of Figure 10-2 follows
Description of "Figure 10-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 10-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 10-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 10-1 describes how a request functions at various stages through its life cycle and how a request attains these stages:

Table 10-1 Request Stages

Request Stage Description

Created

After successful submission of the request, the request moves to the 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 request engine looks at the request template first to find if there are any approvals defined. If it finds any, then 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 Template Approval

  • 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 a 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 request statuses are possible in case the request is provision resource request or modify provision resource request.

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:

  • Template Approval Approved

  • 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:

  • Template Approval Rejected

  • 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.

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 request statuses associated with this stage are Request Failed and Request Partially Failed, which is set based on the failing of all or any of the associated operations specified in the request respectively.

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, as indicated by multiple entry point in Figure 10-2.

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 from Oracle Identity Manager Self Service and cannot be withdrawn from Advanced Administration.

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:

10.2 Bulk Requests and Child Requests

A bulk request is a request with multiple beneficiaries, multiple target 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 deprovisioning bulk request, the requester can select different resource instances to be deprovisioned for different beneficiaries. In such a situation, the association between the resource instances and their beneficiaries is maintained.

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, two user instances are to be modified. For this request, two child requests are spawned addressing one user instance each.

Consider another example. For a deprovisioning bulk request, there are two beneficiaries. Two resource instances are to be deprovisioned for each beneficiary. In this scenario, there are two child requests for the first beneficiary and two child requests for the second beneficiary. Each resource 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.

Template-level approval is performed as a part of parent request. If the request template used to create the request has an associated approval process, then request will move to "Obtaining Template Approval" stage. If the template has no approval process, request will be auto-approved at template level and is moved to "Obtaining Request Approval" stage.

Request-level approval is performed as a part of parent request. After the parent request spawns child requests, the parent request goes to the Operation Initiated stage, where in the request awaits for the child requests to complete the operation-level approval. After all the child requests completes, the parent request moves to the Completed stage, provided the requester is the same for both parent request and child requests.

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 of the child requests fails, then the parent request attains the Partially Failed stage. If all the child requests fail, the parent request attains the Failed stage.

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

Figure 10-3 Bulk Request and Child Request Stages

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

See Also:

10.3 Request Models

A request model is a specification that instructs the request management engine to behave in a specific way for a particular request type. Each request must have a request model associated with it. There is a one-to-one relation between a request model and a request type. A request model dictates what information to collect, how to get the approvals, and what action to perform. For example, the information defined for the Create User and Modify User request models are different, and as a result, the actions for each request type are different.

Note:

Oracle Identity Manager provides the request models by default. Request models cannot be modified.

Oracle Identity Manager provides a set of predefined request models. Table 10-2 lists the operations and request models that Oracle Identity Manager supports by default.

Table 10-2 Default Operations and Request Models

Catalog Request Model Bulk Self or Admin Beneficiary

User Management

Create User

N

Admin

N

 

Self-Register User

N

Self

N

 

Modify Self Profile

N

Self

N

 

Modify User Profile

Y

Admin

N

 

Enable User

Y

Admin

N

 

Disable User

Y

Admin

N

 

Delete User

Y

Admin

N

Provisioning

Provision Resource

Y

Admin

Y

 

Self-Request Resource

Y

Self

Y

 

Modify Provisioned Resource

Y

Admin

Y

 

Enable Provisioned Resource

Y

Admin

Y

 

Disable Provisioned Resource

Y

Admin

Y

 

De-Provision Resource

Y

Admin

Y

 

Self Modify Provisioned Resource

N

Self

Y

 

Self De-Provision Resource

Y

Self

Y

Role Management

Create Role

N

Admin

N

 

Delete Role

Y

Admin

N

 

Modify Role

N

Admin

Y

 

Assign Roles

Y

Admin

Y

 

Remove from Roles

Y

Admin

Y

 

Self-Assign Role

Y

Self

Y

 

Self-Remove Role

Y

Self

Y


Note:

For the Create Role, Delete Role, and Modify Role request models, request creation is supported only by using APIs and not from the UI.

In Table 10-2, the Bulk column indicates the request models for which bulk operations are supported. A bulk request is a request with multiple beneficiaries, multiple target entities, or both. For example, a request to provision multiple roles to user John Doe generates a bulk request. A provisioning request to add users John Doe and Jane Doe to the Managers group also generates a bulk request.

A request model is an XML file that specifies how the request must flow after submission, what approvals are required, and what data is required from the requester. It contains the following information:

10.4 Creating Requests for Self and Others

A user logged in to Oracle Identity Manager can create requests from Self Service and Advanced Administration . This section describes how to create requests by using Oracle Identity Manager Self Service in the following topics:

See Also:

"Creating Requests by Using Oracle Identity Manager Advanced Administration" for information about creating requests as a request administrator by using the Advanced Administration UI

10.4.1 Creating a Request to Register Yourself in Oracle Identity Manager

Using the login page of Oracle Identity Manager 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:

  1. In the login page of Oracle Identity Manager Self Service, click Register. The Step 1: Basic Information page of the User Registration wizard is displayed.

  2. Enter first name, last name, and e-mail ID in the respective fields, and then click Next. The Step 2: Login Information and Security Information page is displayed.

  3. In the Select a User ID and Password section, enter login ID and password, and confirm the password in the respective fields.

  4. In the Set your Challenge Questions and Answers section, select challenge questions and enter answers for the questions. These questions and answers are used if you forget your password and need to reset it.

  5. Click Register. A confirmation page is displayed stating that the registration request is created. This page displays a request tracking number that you can use to check the status of your request.

  6. Click Track Registration to track the self registration requests.

10.4.2 Creating a Request from Oracle Identity Manager Self Service

Oracle Identity Manager Self Service allows you to create requests from the Welcome page, the My Requests page, and the My Profile page, as described in the following sections:

10.4.2.1 Creating a Request From Welcome Page of Oracle Identity Manager Self Service

Using the Welcome page of Oracle Identity Manager Self Service console, a logged in user can create requests for self or for others if authorized.

To create a request from the Welcome Page of Oracle Identity Manager Self Service:

  1. In the Welcome page of Oracle Identity Manager Self Service, click Create Request. The Request Beneficiary Selection page is displayed.

  2. Select Request for Me or Request for Others and click Next. The Select Request Template page is displayed.

    Note:

    • If the Request for Me option is selected, then all templates related to self request types that are accessible to you are displayed.

    • If the Request for Others option is selected, then all templates related to non-self request types that are accessible to you are displayed. If there are no such templates, then you cannot create request with this option.

  3. In the Request Template box, enter the request template name. Alternatively, select the request template from the table. Then, click Next.

    After the template selection, the steps in the request creation are dynamically generated. The subsequent steps are shown if you select the Create User request template.

  4. From the available details list, enter last name and select Organization, Design Console Access, and User Type and then click Next. The Enter Justification page is displayed.

  5. Enter the date and the justification for creating the request and then click Finish. The Request ID is created and displayed.

  6. Click on the Request ID. The request details are displayed.

10.4.2.2 Creating a Request From the My Requests Page

When you click Requests on the top of Oracle Identity Manager Self Service, the My Requests page is displayed.

In the Search My Requests section of the My Requests page, you can search for requests by using the fields in the Search Requests section. A table is displayed in the page that lists the requests raised by you or the requests raised for you.

Table 10-3 lists the columns in the table that shows request information:

Table 10-3 Columns in the Table Showing Request Information

Column Description

Request Type

The type of the request or the operation to be performed by raising the request

Request ID

A unique ID to identify the request

Status

A descriptive indication of the state the request is currently in

Date Requested

Date and time when the request was raised

Requester

The user or the system component that created and submitted the request


To create a request:

  1. From the Actions list, select Create Request. The Request Beneficiary page is displayed.

  2. Select Request for Me or Request for Others and click Next. The Select Request Template page is displayed.

    Note:

    • If "Request for Me" option is selected, all templates related to self request types which are accessible to you are displayed.

    • If "Request for Others" option is selected, all templates related to non-self request types which are accessible to you are displayed. If there are no such templates, you cannot create request using this option.

  3. In the Request Template box, enter the request template name. Alternatively, select the request template from the table. Then, click Next.

    After the template selection, the steps in the request creation are dynamically generated. The subsequent steps are shown if you select the Create User request template.

  4. From the available details list, enter last name and select Organization, Design Console Access, and User Type and then click Next. The Enter Justification page is displayed.

  5. Enter the date and the justification for creating the request and then click Finish. The Request ID is created and displayed.

  6. Click on the Request ID. The request details are displayed.

In the My Requests page, you can also withdraw a request by selecting the request, and then selecting Withdraw Request. For more information about withdrawing requests, see "Withdrawing a Request"".

In the My Requests page, when you click the link in the "Request ID" column, the request details are displayed for that request. For information about the Request Details page and the operations that you can perform in this page, see "Searching for Requests".

10.4.2.3 Creating a Request From the My Profile Page

You can create requests from the My Profile page in Oracle Identity Manager Self Service. The following request types are allowed:

10.5 Searching for Requests

Using Oracle Identity Manager Self Service, various roles perform request searching and tracking:

See Also:

"Searching Requests" for information about searching requests in the Advanced Administration UI

10.5.1 Request Search as a Requester

As an authenticated user, you can view the requests raised by you in the Requests tab of Oracle Identity Manager Self Service. When you click Requests, the My Requests page is displayed with a search facility and a list of requests that you raised. You can search for the following:

  • Requests Raised By Me: Returns requests created by logged-in user

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

In the Search Requests section of the Requests page, you can search for requests based on request ID, request type, status, start date, and end date. You can also sort the requests based on request ID, request type, status, date requested, and requester.

Note:

Sorting on Request ID is string based and not number based.

The search results are displayed in a table. From the Show list, you can select Requests Raised By Me to display the requests for which you are the requester. Otherwise, select Requests Raised for Me to display the requests for which you are the beneficiary.

Note:

In the My Requests page, you cannot perform any action on the requests as a beneficiary. As a requester, you can withdraw the request. See "Withdrawing a Request" for more information about withdrawing requests.

When you select a request in the table, the Request Details tab is displayed with detailed information about the request, as shown in Figure 10-4:

Figure 10-4 The Request Details Tab

Description of Figure 10-4 follows
Description of "Figure 10-4 The Request Details Tab"

The Request Details page displays the details of the request in the Request Information section. The Status field displays the current request status. A link is shown if the status is Request Failed or Request Completed with Errors, as shown in Figure 10-4, which can be clicked to see the reason for the failure.

In addition, the following tabs display details associated to the request:

10.5.1.1 Requested Roles/Requested Resources/Users

The Requested Roles tab is displayed only for the requests that are associated with role management request types. If the request type is associated with provisioning, then the Requested Resources tab is displayed. If the request type is associated with user management, then the Users tab is displayed.

The Requested Roles tab shows the beneficiary and the role display name. For a bulk request, the table in this tab displays all the beneficiary and role names corresponding to each beneficiary, as shown in Figure 10-5:

Figure 10-5 The Requested Roles Tab

Description of Figure 10-5 follows
Description of "Figure 10-5 The Requested Roles Tab"

When you open the request details of a Create User or Provision Resource request type, the Users tab or the Requested Resources tab respectively displays a View Details link. Figure 10-6 shows the View Details link in the Users tab:

Figure 10-6 The Users Tab

Description of Figure 10-6 follows
Description of "Figure 10-6 The Users Tab"

When you click the View Details link, a window is displayed with the user or resource details, as shown in Figure 10-7:

Figure 10-7 The User Details Window

Description of Figure 10-7 follows
Description of "Figure 10-7 The User Details Window"

10.5.1.2 Request Comments

This tab shows the comments associated with the request, if any. You can see all the comments that might be added at various stages of the request life cycle and also add new comments. For example, the requester may add a comment before withdrawing the request, an administrator may add a comment before closing the request, an approver or requester may add comments as a part of attaining approvals.

10.5.1.3 Request History

This tab displays the request history, which consists of various changes the request has been through in the process of execution. Request history shows or tracks only the status changes to an request. The table in this tab shows the status of the request, the date on which the request is updated, and the user who updated the request, as shown in Figure 10-8:

Figure 10-8 The Request History Tab

Description of Figure 10-8 follows
Description of "Figure 10-8 The Request History Tab"

10.5.1.4 Approval Tasks

This tab shows all Approval Tasks (pending or completed) that are associated with the request.

10.5.1.5 Child Requests

This tab is displayed only for a bulk/parent request. It displays the child requests that are created for the bulk/parent request.

10.5.2 Request Search as a Beneficiary

To view the requests for which you are a beneficiary:

  1. Log in to Oracle Identity Manager Self Service.

  2. Click Requests. The My Requests page is displayed.

  3. From the Show list, select Requests Raised For Me. The requests raised for you are displayed in a table as shown in Figure 10-9:

    Figure 10-9 Requests Raised For You

    Description of Figure 10-9 follows
    Description of "Figure 10-9 Requests Raised For You"

  4. Select a request to display detailed information about the request in the Request Details tab.

In the My Requests page, you cannot perform any action on the requests as a beneficiary.

10.5.3 Request Searching by Approver

As an approver, you can view the requests waiting for your approval in the My Tasks section of Oracle Identity Manager Self Service.

In the Search Tasks section of the Approvals tab, you can search for requests based on request ID, task name, start date, and end date. The search results are displayed in a table. From the View Tasks Assigned To list, you can select the following:

  • You Only: To sort only the requests assigned to you

  • Roles You Have: To sort the requests assigned to the roles of which you are a member

  • You and Roles You Have: To sort the requests assigned to you and to the roles of which you are a member

  • Users You Manage: To sort the requests assigned to the users you manage

When you select a request from the search results table, the Task Details page is displayed with detailed information about the request.

The request details are displayed in the Basic Details and Request Information sections.

If some attributes are marked as approver-only in the request type/dataset, then there will be an additional section called "Additional Data From Approver". It is in this section, where approver can provide data, without which the approver will not be allowed to approve a request (if the field is marked as mandatory). In the next level of approval, the approver can modify the data, if required.Similarly, if the approver send a task to a user for additional information, then task details of the received user will have an additional section called "Additional Request Information". It is in this section, where a received user can provide the information requested.

In addition, the following tabs display details associated to the request:

  • Requested Resources or Users or Requested Roles: The Resources tab is dynamically generated based on the request type. It displays a list of beneficiaries, name of the target resources, and links to view the details about the target resources.

    The User tab shows the user details that is part of a request. For example, in case of CreateUser, User tab displays the user name and "View Details" link will provide the attributes of the user provided during the request creation.

    The Role tab shows the role details that is part of a request. For example, it can be a role name that you want to add or remove.

  • Request Comments: This tab displays any comment or justification provided with the request.

  • Request History: The various changes the request has already been through in the process of execution.

From the My Tasks and the Request Details tabs, you can perform request operations, such as approving, claiming, rejecting, and reassigning requests, and to request for more information. For detailed information about these procedures, see "Chapter 9, "Managing Tasks".

10.5.4 Request Search by Unauthenticated User

As an unauthenticated user, you can only track the request for self-registration. After you create and submit a self-registration request, a request ID is displayed. You can use this request ID to track the request.

See Also:

"Tracking Registration Requests" in the "Unauthenticated User Self Service" chapter for information about tracking a self-registration request

10.6 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 Oracle Identity Manager Self Service, click Requests.

  2. In the My Requests page of Oracle Identity Manager Self Service, select the request that you want to withdraw.

  3. From the Actions list, select Withdraw Request.

  4. Click OK 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.

10.7 Performing Request-Related Tasks by Using the Task List

For more information about request-related tasks, such as approving a request, claiming a task, requesting for more information, submitting information, rejecting a task, and reassigning a task using the Task List, see "Viewing Task Details" in the "Authenticated User Self Service" chapter.

10.8 Closing Requests

Request Administrators (users with Request Administrators role) 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. Go to Oracle Identity Manager Advanced Administration.

  2. In the left pane of the Requests section, search for the request that you want to close.

  3. From the search results table, select the request.

  4. From the Actions list, select Close Request. The Close Request dialog box is displayed.

  5. Enter a reason for closing the request, and then click Close Request. A message box is displayed stating that the request closing is successful.

  6. Click OK. If the request is closed successfully, then the request moves to the Request Closed stage. A notification that the request is closed is sent to the requestor and target user for this request.

    Note:

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