Provisioning claims
When a resource assignment is to be provisioned or deprovisioned, RoPE creates a provisioning task for the provisioning mechanism selected for the system which the resource belongs to.
If the provisioning mechanism is a manual task or the Omada Provisioning Service, RoPE receives a provisioning claim for each of the actions (add/modify/remove) when the provisioning task is complete.
RoPE considers the claims when calculating the identity for whom the claim exists. If an active claim exists, the CRA gets an unconfirmed actual reason, which counts as an actual state reason in the same way as an actual direct reason does.
When a claim represents the most recent known actual state, its recorded values can be used when RoPE determines whether an assignment should enter Pending Update. For details about how claims and Warehouse records are compared with the desired state, see Attribute and state comparison when both desired and actual state exist.
By default, a provisioning claim expires after two days.
You can change this default by setting a higher number of days in the PROVCLAIMEXPIREDAYS property on the system. You can also set the value to -1, which means that the claim never expires.
The -1 value should be used in offline systems where you do not expect further updates on the assignment from the Warehouse. In addition, the provisioning status of such an assignment is set to OK instead of OK (Pending Confirmation).
After a provisioning claim expires, a new provisioning task is created if the result of performing the provisioning task is not detected by the Omada Identity Data Warehouse before that time. Implicitly assigned compound resources and their child resources are neither considered part of the desired state nor part of the actual state.
A provisioning claim is ignored if a record exists in the Omada Identity Data Warehouse, representing an actual state reason, that is newer than the provisioning claim.
Each provisioning claim can be in one of the four states:
- Queued — The provisioning job has been accepted and queued in OPS for execution.
- Relayed — A provisioning task, typically a manual one, has been created in an external provisioning system, for example an ITSM system.
- Failed — The external provisioning system to which the task was relayed, for example ITSM or SAP GRC, refused to perform the assigned task, or OPS was unable to perform it after a number of retries due to, for example, a licensing issue or long-lasting network outage.
- Done — Provisioning has been performed successfully in the target system.
The Queued claim does not result in recalculation of an identity by RoPE. This is because the Queued claim does not affect the provisioning status of a CRA.
For Relayed and Failed claims, the expiration date is by default set to 10 days and -1 (never), respectively.
Attributes recorded in a provisioning claim
When Omada Identity creates a provisioning claim, it records the full set of provisioning-relevant attribute values as they were at the time the provisioning task was executed.
This includes all attributes defined in the Provisioning attribute set (SYNCPROVATTRS property on Resource Type), or all assignment attributes if no provisioning attribute set is defined, as well as the account name and disabled flag.
This is broader than the Reconciliation attributes used for Warehouse comparison. The claim captures all provisioning-relevant attributes so that Omada Identity can detect attribute drift during the period before the Warehouse confirms the outcome.
These recorded values can be used when RoPE evaluates whether an assignment should enter Pending Update. For more information about how claim values are compared with the current desired state, see Attribute and state comparison when both desired and actual state exist.
You can inspect the provisioning attributes recorded in a claim in the Provisioning Claims view in the Omada Identity portal. The Attributes column shows the provisioning-relevant attributes recorded for the claim.
A provisioning claim for an Active Directory permission assignment might record { "VALIDFROM": "2025-01-01", "VALIDTO": "2026-12-31", "DEPARTMENT": "Finance" } — all values that were active at the time the assignment was provisioned.
If VALIDTO is later updated in Omada Identity, the next recalculation can detect the difference against these recorded values and set the assignment to Pending Update.
For information about identifying the condition that triggered Pending Update in the calculation results, see Viewing the provisioning status of an assignment.
Searching for provisioning claims
When searching for provisioning claims by Identity ID, a direct search does not necessarily return matching results. To find all provisioning claims for a given Identity ID, use a wildcard search pattern (%) before the value, for example %12345.
| Search | Result |
|---|---|
12345 | May not return any results |
%12345 | Finds claims that contain that Identity ID |