You use the
tab to define the basic information about the provisioning request definition (for example, the name of the provisioning request definition, the category to which it belongs, who can access it).Figure 5-1 Overview Tab
The following table describes each property that you can configure on the
tab.Table 5-1 Overview Properties
Field |
Description |
---|---|
|
Displays the CN (common name) of the provisioning request definition. The CN cannot be changed. |
|
Specifies the display name of the provisioning request definition. This is the name that is displayed to the user in Designer and Identity Manager. |
|
Specifies the description of the provisioning request definition. |
|
Specifies the category to which the provisioning request definition belongs from the list of Provisioning Categories defined in the directory abstraction layer. The Provisioning view displays the provisioning request definitions by categories. |
|
Specifies the status of the provisioning request definition: Active: Select this option to make the provisioning request definition available for use in the User Application. Inactive: Select this option to make the provisioning request definition temporarily unavailable for use in the User Application. You can use this option when you want keep the roles of the person who develops and deploys the provisioning request definition separate from the person who activates the provisioning request definition. For example, a developer could deploy the provisioning request definition as Inactive, and an administrator could be responsible for changing the status to Active. Template: Select this option if you want to use this provisioning request definition as the basis for other provisioning request definitions. Templates are not available for use in the User Application. Retired: Select this option to mark the provisioning request definition as permanently unavailable for use in the User Application (you can still change the status of the provisioning request definition at any time). This status provides a way of keeping a historical record of a provisioning request definition that is no longer in use. |
|
Specifies the flow strategy for the provisioning request definition: Single Flow: This strategy allows one workflow with one recipient. Flow per member: This strategy allows the recipient to be a group DN. If you select this strategy, the User Application starts a workflow instance for each member of the group, and each workflow can be approved or denied separately. For example, if there is a provisioning request definition for the recipient Human Resources. The Human Resource group has the members ablake and kchester. The User Application passes the Human Resources DN to the provisioning start. The provisioning interface starts two workflow instances; one for ablake and one for kchester. Single Flow Provision Members: This strategy allows the recipient to be a group DN. If you select this strategy, the User Application starts a single workflow for the group. The workflow spawns multiple provisioning steps (one for each member) within the single workflow. The workflow is approved or denied to the group as a whole not for each individual member. |
|
Specifies whether approvers are notified by e-mail about pending approval tasks, and whether initiators are notified by e-mail of workflow completion. If Notify participants by email is not checked, then users must look at the tab in the User Application for notifications about tasks.For information about selecting an e-mail template and customizing e-mail template parameters, see Section 8.10, Finish Activity. |
|
Specifies that the list of tasks that can be viewed by the user in My Requests in the User Application is restricted to tasks initiated by the user. The default behavior (that is, is not selected) is that the user can see any requests that the user initiated or for which the user is the recipient. |
|
Specifies that the workflow engine should generate comments as the workflow progresses. These comments can be displayed by clicking the following: |
|
Specifies that the default completion status of the provisioning request is approved if selected, or denied if not selected. This feature can be useful for provisioning requests that do not contain a provisioning activity (an Entitlement or Entity). The value of this parameter can be overridden by explicitly setting the completion status using a Provisioning activity or Workflow Status activity. |
|
Specifies the users and groups that can use the provisioning request definition. |
You can set these access the properties available on the Overview panel for one or more provisioning request definitions.
With the Provisioning view open, select one or more provisioning request definitions, right-click, then select
. The following screen displays.To modify a property for all of the selected provisioning request definitions, make that change.
If one of the properties does not contain a value, the corresponding field is blank. If you modify that field, then the value you select is applied to all of the selected provisioning request definitions.
For Trustees, you can delete, add, or merge the values for the selected provisioning request definitions. To merge the values, select the <>. This adds all of the trustees for any selected provisioning request definition to all of the selected provisioning request definitions.