9.2 Configuring Fulfillment

You can configure each application to use multiple fulfillment targets. For example, you might have one system that processes all requests to add access and a different system that processes all requests to remove access.

You can transform the incoming data from fulfillment targets to have Identity Governance display more meaningful information. For example, instead of displaying only the incident number from your fulfillment system, you could display additional text, such as “Incident number 123456 was created in ServiceNow” in Identity Governance.

The transforms are done through Nashorn-compatible Javascript in the Fulfillment Response mapping section of the fulfillment target configuration. Within the Javascript, you can access the incoming value by creating a variable name inputValue. After manipulating the incoming value, you can return the value to Identity Governance by assigning the value to a variable name outputValue.

The following example transforms the incoming value, which is a tracking number from the connected system to Incident number 123456 created in ServiceNow in the Identity Governance displays.

outputValue = 'Incident number ' + inputValue + ' created in ServiceNow'

For Identity Manager automated, Identity Manager workflow, and manual fulfillment methods, Identity Governance evaluates and fulfills the change items without the need for extensive configuration. When specifying one of the default methods of fulfillment, observe the following considerations:

Identity Governance includes connectors to various service desk products to enable fulfillment integration with your incident management applications. When you connect to an application for fulfillment, you must configure the connector to map the data fields in the change item to the input fields of the application. In a typical service desk environment, all systems and applications that the service desk manages are input as configuration management items.

The Identity Governance Fulfillment target configuration allows you to customize your incidents for these various systems. When you create a service desk fulfillment target in Identity Governance, you provide the connection information and credentials for the target system as well as a default configuration specifying the fields you want Identity Governance to populate in your incidents. After you assign a target fulfillment system to an application, you can then customize that default configuration to appropriately map the application configuration item, assignment group, severity, and other fields for that specific application.

Identity Governance exposes the following data fields from each changeset item to the fulfillment target connectors:

The following shows a sample change item payload:

{
    "accountProvId": "d2a293ff-71c5-492f-9415-e08830b635b2",
    "changeItemId": 8300,
    "changeRequestType": "REMOVE_PERMISSION_ASSIGNMENT",
    "userName": "Abby Spencer",
    "accountName": "aspencer",
    "account": "CN=Abby Spencer,OU=Users,OU=MyServer,DC=mydc,DC=mycompany,DC=com",
    "appName": "Money Honey Financials",
    "reason": "REMOVE_PERMISSION_ASSIGNMENT remove permission Marketing Portal requested by Aaron Corry while certifying Money Honey Financials",
    "requesterName": "Andrew Astin",
    "permName": "Marketing Portal",
    "permProvAttr": "member",
    "permProvId": "e07db779-5c30-44d2-bc0c-6dfa30cfa6af"
}

Mapping Identity Governance change item data to target application data fields is similar to configuring data source collectors. This includes support for static-value mapping and per-field data transformation. For more information, see Section 2.2, Customizing the Collector Templates for Data Sources.

Since the implementation of any particular service desk application varies widely for each customer, it may be useful to manually create sample incidents using the application user interfaces to validate the desired inputs for each fulfillment method.

The fulfillment status list allows you to view specific status categories, such as fulfillment items that have been fulfilled and fulfillment items that have ended in error or timeout conditions. The fulfillment status area also provides a way to retry, or resubmit, fulfillment items that did not succeed.

The following details on fulfillment status conditions can help with troubleshooting fulfillment in your environment. A change item has 11 possible status conditions, listed below in the associated status column. The general status column shows the broad status categories that Identity Governance displays to users. The table includes details on each status and what actions, if any, you can take to move an item to a different status. No user action is required for some status conditions, either because they are intermediate states or terminal states.