Object Reference for the Salesforce Platform
j
No Results
Search Tips:
- Please consider misspellings
- Try different search keywords
UserProvisioningRequest
A UserProvisioningRequest (UPR) record is created for each provisioning action for each user, and for each connected app available to the user. For example, if a user has two connected apps, and a provisioning request is sent to two different services to create an account for the user, Salesforce creates two UPR objects. Provisioning actions include creating, updating, or deleting a user account.
Supported Calls
create(), delete(), describeLayout(), describeSObjects(), getDeleted(), getUpdated(), query(), retrieve(), undelete(), update(), upsert()
Fields
| Field | Details |
|---|---|
| AppName |
|
| ApprovalStatus |
|
| ConnectedAppId |
|
| ExternalUserId |
|
| ManagerId |
|
| Name |
|
| Operation |
|
| OwnerId |
|
| ParentID |
|
| Retry Count |
|
| SalesforceUserId |
|
| ScheduleDate |
|
| State |
|
| UserProvAccountId |
|
| UserProvConfigId |
|
Usage
The State value changes during a reconciliation process (Operation = Reconcile) to gather and compare users on the third-party system to Salesforce users. Typically, when a UPR entry is first created, it has a State value of New. When a collection process is triggered, the State transitions to Collecting until that process is finished and the State is Collected. When an analyze process is triggered, the State transitions to Analyzing until that process is finished and the State is Analyzed. If a process commits the request, the State then transitions to Committing, and the properties move from the UserProvAccountStaging object to the UserProvAccount object. When those properties are saved in the UserProvAccount object, the State transitions to Completed.
However, the State does not necessarily start at New. For example, UserProvAccountStaging entries can be inserted programmatically. If a process is initiated that triggers linking these rows to accounts on the third-party service, a UPR entry could start with the Analyzing State.
Also, the State cannot go backwards from an active task. For example, a successful Analyzing State must progress to Analyzed; unless the active process fails, and then the State must change to Failed. Certain State transitions cannot be made programmatically and must be triggered by Salesforce.
-
— the transition to this value is not allowed. -
— the transition to this value is allowed. -
— only Salesforce can transition the State to this value.
| New | Requested | Collecting | Collected | Analyzing | Analyzed | Committing | Completed | Failed | Retried | Manually Completed | |
|---|---|---|---|---|---|---|---|---|---|---|---|
| New | |
|
|
|
|
|
|
|
|
|
|
| Requested | |
|
|
|
|
|
|
|
|
|
|
| Collecting | |
|
|
|
|
|
|
|
|
|
|
| Collected | |
|
|
|
|
|
|
|
|
|
|
| Analyzing | |
|
|
|
|
|
|
|
|
|
|
| Analyzed | |
|
|
|
|
|
|
|
|
|
|
| Committing | |
|
|
|
|
|
|
|
|
|
|
| Completed | |
|
|
|
|
|
|
|
|
|
|
| Failed | |
|
|
|
|
|
|
|
|
|
|
| Retried | |
|
|
|
|
|
|
|
|
|
|
| Manually Completed | |
|
|
|
|
|
|
|
|
|
|
State Values for Managing Provisioning Failures
The state value changes to Failed for several reasons, such as network outages, session timeouts, permissions issues, and record locks. The Failed state can transition to either Retried or Manually Completed to indicate what action was taken to address the failure. Actions can include correcting the root cause of the failure and requesting that the provisioning engine retry the UPR. Or, it can be completing the action against the target manually. Each UPR is an independent transaction and it’s possible the retry causes a failure with a different root cause. So it’s hard to distinguish failed events that you addressed from the ones that require more action.
If you tried to correct the cause of the failure and requested the provisioning engine to retry the UPR, you can mark the failed UPR Retried. Or, if the action against the target was completed manually, you can mark it Manually Completed.
When a retry event is created, the failed UPR is cloned, and resubmitted. The ParentID field contains a lookup to the failed UPR to use to clone the new UPR. The Retry Count field contains the number of retry attempts that were performed on a UPR. With the Retry Count field, you can add custom business logic like "Retry 5 times then stop and notify your admin."
Associated Objects
This object has the following associated objects. Unless noted, they are available in the same API version as this object.
- UserProvisioningRequestOwnerSharingRule (API version 34.0)
- Sharing rules are available for the object.
- UserProvisioningRequestShare (API version 34.0)
- Sharing is available for the object.