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. 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. Along with an operation, a subset of the entity attributes is specified as operational parameters to carry out that particular operation. 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 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 the request is submitted to the next level. 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.

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:

• Request Stages

• Bulk Requests and Child Requests

• Request Models

• Creating Requests for Self and Others

• Searching for Requests

• Withdrawing a Request

• Performing Request-Related Tasks by Using the Task List

• Closing Requests

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 Request Stages"

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 attains the Submitted stage, 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 of that instance. 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:

• Submit request

• Close/cancel (withdraw) request

• Approve request when the service is notified that the approval workflow is successfully approved

Examples of automatic operations are:

• Start approvals when the request is submitted

• Execute request when the request is approved and execution date is in the past or not specified

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 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 bulk request has two parts:

• Parent requests: A request submitted with multiple beneficiaries, multiple target entities, or both is a parent request

• Child requests: When the request level approval happens for a parent request, multiple child requests are created. The parent request is divided into multiple child requests containing one beneficiary and one target entity, or both.

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 deprovisioning bulk request, there are two beneficiaries. For the first beneficiary, three resource instances are to be deprovisioned and for the second beneficiary, two resource instances are to be deprovisioned. In this scenario, there are three 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 five child requests.

Consider another 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.

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 statehouse 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, then the parent request will attain the Completed stage. If one of the child requests fail, then the parent request attain the Partially Failed stage. If all the child requests fail, the parent request attain 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 Bulk Request and Child Request Stages"

See Also:

• Table 17-1, "Default Request Templates" for information about the request models that support bulk request

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

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:

• Name of the model

• Whether or not a beneficiary is required:

  • The requests in which a resource is provisioned to a user have a beneficiary. An example of this type of request is a request to create an entity and a relationship between a user or organization with that entity. Specifically the relationship is a 'has a' relation.

  • Requests such as creating a user require creation of an entity, but they do not necessarily have a "has a' relation with any other entity.

• The beneficiary type that is being addressed, which is user.

• The entity-type that the model is associated with and whether or not the entity is a generic one.

  • A generic entity type is a parent entity type for which the creation of entities is not possible unless a specific subtype is selected. For example Resource is a generic entity, where E-mail and Laptop are subtypes.

  • If the entity type can be created without defining subtypes, then it is not a generic entity, such as user.

• Whether or not the model is a creation model. A creation model results in the creation of an entity. It creates an entity and its relation with a user or organization if the model has a beneficiary. A non-creation model requires a target entity to be selected.

• Reference to data collection. A model contains an implicit connection to an XML element to determine the data that needs to be collected. For a generic entity, the final reference is constructed by using the entity subtype selected at runtime, which allows the collection of different data for different entity subtypes.

• Approval workflow selection. A model may contain a reference to the algorithm(s) that are used to select the approval process to be associated for a request. The parameters to be passed to the algorithm are also mentioned.

• Whether or not the model supports an operation that is to be performed in bulk mode.

• Whether or not authentication is required. If true, then a model is available to all authenticated users creating requests. If false, then it is only available through unauthenticated self service, and not available in the authenticated self service.

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:

• Creating a Request to Register Yourself in Oracle Identity Manager

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

• Creating a Request By Using the Authenticated Oracle Identity Manager Self Service

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 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 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 "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 with this option.

3. From the Request Template list, select the type of request and click Next. The Enter Details page is displayed.

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.3 Creating a Request By Using the Authenticated Oracle Identity Manager Self Service

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

In the My Requests form, you can search for requests by using the fields in the Search Requests section. A table is displayed in the form 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
Requestor	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. From the Request Template list, select the type of request and click Next. The Enter Details page is displayed.

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 form, 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 form, 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".

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

• Requesting roles: See "Requesting Roles" for details.

• Removing roles: See "Removing Roles" for details.

• Requesting a resource: See "Requesting a Resource" for details.

• Modifying a resource: See "Modifying a Resource" for details.

• Removing a resource: See "Removing a Resource" for details.

10.5 Searching for Requests

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

• Request Search as a Requester

• Request Search as a Beneficiary

• Request Searching by Approver

• Request Searching by Unauthenticated User

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 form 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 form, 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 the Request ID.

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.

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 The Request Details Tab"

The Request Details page displays the details of the request in the Request Information section. In addition, the following tabs display details associated to the request:

• Role/Resources/Users

• Request Comments

• Request History

• Approval Tasks

10.5.1.1 Role/Resources/Users

The Role tab is displayed only for the requests that are associated with Role Management models. If the request type is associated with provisioning, then the Resource tab is displayed. If the request type is associated with user Management, then Users tab is displayed.

The Role 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 Role Tab

Description of "Figure 10-5 The Role Tab"

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

Figure 10-6 The Request History Tab

Description of "Figure 10-6 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.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 form is displayed.

3. From the View Requests list, select Raised For Me, and then click Apply. The requests raised for you are displayed in a table as shown in Figure 10-7:

   Figure 10-7 Requests Raised For You

   
   Description of "Figure 10-7 Requests Raised For You"
   
   

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

In the My Requests form, you cannot perform any action on the requests as a beneficiary, except for withdrawing the request. See "Withdrawing a Request" for more information about withdrawing requests.

10.5.3 Request Searching by Approver

As an approver, you can view the requests waiting for your approval in the All Tasks section of Oracle Identity Manager Self Service. Figure 10-8 shows the Approvals tab of the All Tasks section:

Figure 10-8 The Approvals Tab

In the Search Tasks section of the Approvals tab, you can search for requests based on task name, start date, and end date. The search results are displayed in a table, as shown in Figure 10-8. 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, as shown in Figure 10-9:

Figure 10-9 The Task Details Page

Description of "Figure 10-9 The Task Details Page"

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

If some attributes are marked as approver in 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. 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:

• Resources or User or Role: 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. The comments recorded are questions and responses for Request for Information. For example, the comments that an approver requests for additional information from the user and the response provided by the user to those queries are recorded in this section.

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

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

10.5.4 Request Searching 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:

• Obtaining Request Approval

• Obtaining Operation Approval

• Approved

To withdraw a request:

1. In Oracle Identity Manager Self Service, click Requests.

2. In the Requests form 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.

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:

• Obtaining Template Approval

• Obtaining Request Approval

• Obtaining Operation Approval

• Approved

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 asking for confirmation to close the request.

6. Click OK to confirm. A notification that the request is closed is sent to the requestor and target user for this request.