Understanding Request Enrichment

Request enrichment enables approvers on a policy to modify request items before approving the request. The items and actions that can be modified depend on the approver's permissions and data access in the view.

When you enable enrichment on an approval policy, any approver on the policy who has Participant (Write) permission on at least one data object in the view can perform enrichment during the approval phase. The actions that an enricher can take depend solely on the permissions and data access of the enricher in the view.

Note:

The data access of the request submitter is not taken into account. This means that an enricher can potentially perform actions in a request that the original request submitter could not.

The changes that an enricher can make are not limited to the policy or the data objects in the original request. If enrichment is enabled on any policy on any data object in a request, enrichers can perform any request action in the view that their permissions and data access allows.

For example, suppose you have a maintenance view that contains viewpoints for a general ledger application and a Planning application, and your general ledger application has an approval policy with enrichment enabled. When a request to add a cost center to the general ledger is submitted, if an approver on the GL policy also has Participant (Write) access to the Planning application, they can add the cost center to the Planning application as well before approving.

Considerations

• If an approver is included in more than one policy on a data chain object, the approver can enrich the request if any of the policies has enrichment enabled on it.
• The enricher must be currently invited in order to make changes to a request. If the request is not in the Approval stage (for example, if another approver pushed the request back), the enrichers can not make changes to the request.
• When determining the request actions and property updates that an enricher can perform, the permissions and data access in the view of the enricher are taken into account (see Configuring Data Access). For example:
  • If an enricher has data access to perform only Adds in a node type, they cannot add or delete a request item to Delete a node.
  • If an enricher has Display only access to a property, they cannot add or delete a request item to modify that property.
• Enrichers can perform request actions that negate or change previous actions performed by the submitter or other enrichers.

Validating and Approving Enriched Requests

Whether or not an enricher makes changes to a request, since enrichers are also approvers they must approve the requests that are assigned to them. When an enricher approves the request, data validations are performed based on the enricher's permissions and data access. The validation and approval process is as follows:

• If a validation error occurs:
  • If the approver is an enricher and is responsible for any actions that failed validation, the request is not approved. The request remains open in the view, and a message indicating the validation failure is displayed. The enricher must take action on the request to correct the validation failure, either by correcting any data issues, pushing the request back to the submitter, or rejecting the request.
  • If the approver is not responsible for any actions that failed validation, the request is approved and new invitees are calculated.
• If no validation errors occur, the request is approved and new invitees are calculated.

When all approval policies have been satisfied, if there are still validation errors the submitter is notified. The submitter can delete any request items that are causing the validation issues, including request items that contain actions or properties that the submitter's permissions and data access don't include.

When no validation errors remain, the request is committed.