Provisioning Requests

>Prerequisites for Viewing and Managing Provisioning Requests

>Request Status

>Actions for Provisioning Requests

Prerequisites for Viewing and Managing Provisioning Requests

A role that includes Entitlement and/or Activation Management permissions. At minimum, you need:

>View permission to view a provisioning request.

>Edit permission to manage a provisioning request.

For details, see Roles.

Request Status

The Status of a provisioning request can be one of the following:

Status	Description
Request Sent	Indicates that a provisioning request was sent to the provisioning endpoint.
Request Queued	Indicates that a provisioning request was initiated and is in the queue.
In Progress	Indicates that the provisioning request is currently being handled by the provisioning system.
Completed	Indicates that the provisioning request was successfully processed by the provisioning system.
Dispatch Failed	Indicates that the provisioning request could not be sent.
Failed	Indicates that the provisioning request could not be processed by the provisioning system. This can occur for many reasons, such as a missing or inaccurate provisioning plan or method, validation issues, or the provisioning endpoint might be unavailable.

Provisioning Attributes

The following table describes the attributes that are available on the Provisioning Requests page.

Attribute	Description
Status	Status of the provisioning request, as described in Request Status.
Product	Name of the product associated with the request.
Product ID	Numeric identifier for the product. This refers to the product associated with the request.
EID	Entitlement ID. A unique identifier for an entitlement.
AID	An auto-generated GUID (Globally Unique Identifier) that is assigned to activations, for example: q5251rst-69q6-49qz-qrs5-45q225r9375s
Activated Quantity	Number of provisions consumed in the activation. For example, this might be the number of accounts or services that were provisioned.
Comments	Comments related to the provisioning request.
Plan	Plan associated with the request. A plan includes a set of static and/or dynamic expressions that are used by the provisioning endpoint to provision the activated products. You create plans in Sentinel EMS. For details on creating a plan, see Provisioning Plans. For details on managing the associated plan, see Managing Provisioning Associations.
Method	Method associated with the request. A method specifies the data required to send a provisioning request. For details on creating a method, see Provisioning Methods. For details on managing the associated method, see Managing Provisioning Associations.
Status Update Date	The date and time that the request status was last updated. The default time zone is UTC.

Actions for Provisioning Requests

The following table lists the actions available for provisioning requests.

Action	Description
	Update Status	You can update the following: >Status: The status of the provisioning request. •In Progress: The request was initiated in Sentinel EMS and is in progress. •Completed: The request is successfully executed. •Failed: The request failed. Note: The minimum role permissions to update the status of a request are: View and Edit permissions for entitlements. >Provisioning Details: Records information about what was set up during the provisioning process. You can include details such as account or tenant information, system references, or notes from the target application. This information helps track what was configured and can assist when reviewing or troubleshooting the provisioning request later. Since this field is not intended for storing sensitive information, avoid adding private or confidential data such as passwords, secrets, or personal data. >Comments: Additional remarks related to the provisioning request status update. The Comment section serves two main purposes: •Capturing error details on failure: When a provisioning request fails, the system records the detailed error message in this section. This helps identify and track the exact reason for the provisioning failure. •Providing notes during manual status updates: When the request status is updated manually, comments can be added to explain the reason for the change, share progress updates, or provide any additional context related to the provisioning request.
	Retry Request	Resends a failed provisioning request to the configured provisioning method. This action is available only for requests in Failed or Dispatch Failed status. >When to use: You can use this action to retry a request after: •Resolving transient issues, such as network errors, receiver downtime, or email delivery failures (for example, incorrect recipient addresses or a misconfigured email template). •Correcting configuration issues related to the provisioning method endpoint, authentication profile, or missing Method-Plan associations. For example, a request may initially fail because of a missing Method-Plan association. After you add the association, clicking Retry Request triggers a successful retry. >Before you retry: Resolve the underlying cause of the failure. •What you can change before retry: You can edit the existing provisioning method configuration, and then retry the request. For details on method attributes, see Provisioning Methods. •What you cannot change before retry: You cannot change the provisioning method or plan during a retry. Any changes to the provisioning plan configuration made after the provisioning request was created are also not reflected when the request is retried. >Retry behavior: When triggered, the retry follows this workflow: •Confirmation: A confirmation dialog appears. On confirmation, the system re-triggers the request from the beginning of its lifecycle and reuses the existing provisioning process. It does not create a new request or introduce a new status. •Status transitions: If the retry succeeds, the status moves forward to Request Queued or Request Sent (depending on the receiver response). If it fails again, the request returns to a failed state and remains eligible for another retry. •No retry limits: There is no limit on the number of times you can retry a request. >Alternative API Option: You can instead use the Retry Failed Provisioning API, which also records the retry timestamp and retry count each time you retry a request. >Permissions: This action is available to administrators and standard users with catalog permissions.

Action

Description

Update Status

You can update the following:

>Status: The status of the provisioning request.

•In Progress: The request was initiated in Sentinel EMS and is in progress.

•Completed: The request is successfully executed.

•Failed: The request failed.

Note: The minimum role permissions to update the status of a request are: View and Edit permissions for entitlements.

>Provisioning Details: Records information about what was set up during the provisioning process. You can include details such as account or tenant information, system references, or notes from the target application. This information helps track what was configured and can assist when reviewing or troubleshooting the provisioning request later.

Since this field is not intended for storing sensitive information, avoid adding private or confidential data such as passwords, secrets, or personal data.

>Comments: Additional remarks related to the provisioning request status update. The Comment section serves two main purposes:

•Capturing error details on failure: When a provisioning request fails, the system records the detailed error message in this section. This helps identify and track the exact reason for the provisioning failure.

•Providing notes during manual status updates: When the request status is updated manually, comments can be added to explain the reason for the change, share progress updates, or provide any additional context related to the provisioning request.

Retry Request

Resends a failed provisioning request to the configured provisioning method. This action is available only for requests in Failed or Dispatch Failed status.

>When to use: You can use this action to retry a request after:

•Resolving transient issues, such as network errors, receiver downtime, or email delivery failures (for example, incorrect recipient addresses or a misconfigured email template).

•Correcting configuration issues related to the provisioning method endpoint, authentication profile, or missing Method-Plan associations. For example, a request may initially fail because of a missing Method-Plan association. After you add the association, clicking Retry Request triggers a successful retry.

>Before you retry: Resolve the underlying cause of the failure.

•What you can change before retry: You can edit the existing provisioning method configuration, and then retry the request. For details on method attributes, see Provisioning Methods.

•What you cannot change before retry: You cannot change the provisioning method or plan during a retry. Any changes to the provisioning plan configuration made after the provisioning request was created are also not reflected when the request is retried.

>Retry behavior: When triggered, the retry follows this workflow:

•Confirmation: A confirmation dialog appears. On confirmation, the system re-triggers the request from the beginning of its lifecycle and reuses the existing provisioning process. It does not create a new request or introduce a new status.

•Status transitions: If the retry succeeds, the status moves forward to Request Queued or Request Sent (depending on the receiver response). If it fails again, the request returns to a failed state and remains eligible for another retry.

•No retry limits: There is no limit on the number of times you can retry a request.

>Alternative API Option: You can instead use the Retry Failed Provisioning API, which also records the retry timestamp and retry count each time you retry a request.

>Permissions: This action is available to administrators and standard users with catalog permissions.