Provisioning status

When RoPE processes an identity, it computes a provisioning status for each of the identity’s account- and permission assignments.

The provisioning status of an assignment is used by RoPE to determine if it should issue a new provisioning job, either as a manual provisioning task or as an OPS task, in order to align the desired and actual state of the assignment.

RoPE assigns a Provisioning status to each calculated assignment that is stored in the ProvisioningStatus attribute.

The provisioning status is derived from the assignment reasons of the calculated resource assignment, each of which is associated with either the desired state or the actual state. An assignment's attribute values and whether the assignment is disabled can also affect the status.

tip

For information about inspecting provisioning status and identifying what caused Pending Update, see Viewing the provisioning status of an assignment.

Provisioning status values

The provisioning status can have one of the values listed below:

OK (OK)

No provisioning, deprovisioning, or update needs to take place, and we have received confirmation from the Warehouse, if applicable, that this is the case.

For an assignment to be OK, one or more of the following must be true:

• The assignment in the target system corresponds to how it appears in Omada Identity. It has a desired state as well as an actual state reason. This state includes attribute values relevant for provisioning if attribute reconciliation is enabled on the resource type.
• The assignment is for an application role or enterprise role, and all its child resources are OK.
• Provisioning is not enabled because the system to which the resource belongs is configured with Provisioning Type None, or the assigned resource is configured to skip provisioning.
• The assignment is an account that would otherwise be Pending Deprovisioning because it is managed and does not have a desired state reason, but because the system does not support account deletion and the account is disabled in the target system, the status instead becomes OK.
• The assignment is an account with no actual state, and provisioning is skipped because the account is disabled by a violation that prevents provisioning.
• There was no direct reason and a provisioning claim has a status other than Done.
• There was no direct reason and the assignment is based solely on the presence of a Deprovisioning Failed claim.

Pending Provisioning (PendingProv)

The assignment is pending being provisioned, or created, in the target system.

For a resource assignment to be Pending Provisioning, all the following must be true:

• The assignment has a desired state, is not represented in the Warehouse, and there is no provisioning claim for it.
• The assignment is not skipped because it is an account disabled by a violation that prevents provisioning.
• The assignment must not depend on, and wait for, another assignment to be provisioned first.

Also, the following may be true:

• The assignment is for an application role or enterprise role, and one or more of its child resources is Pending Provisioning.

Disabled assignments with desired state but no actual state

When an assignment has a desired state but no actual state, the resulting status is normally Pending Provisioning. This also applies to account assignments that are disabled because of pre-validity or post-validity.

For example, an account can be calculated before its valid from date and remain disabled during the pre-validity period. If the account does not exist in the target system, provisioning is still requested so that the account can be created and later enabled when it becomes valid. The same applies if the target account was deleted and must be recreated.

Permissions behave differently. When a permission assignment is disabled, its desired state is cleared. Therefore, a disabled permission with no actual state is considered OK and does not become Pending Provisioning.

Account assignments can also be disabled because provisioning is prevented by a violation. If the account has no actual state, deprovisioning is skipped and the status is OK. This prevents the connector from receiving a create operation followed by a disable operation for an account with no valid access.

This behavior applies only to account resources and only when the violation prevents provisioning. The following violation statuses prevent provisioning:

• No Override
• Not Allowed
• Decision Pending (Not Allowed)

The following violation statuses do not prevent provisioning:

• Decision Pending (Allowed)
• Allowed

The behavior that disables an auto-created account when all its assignments are blocked is controlled by the customer setting DisableAutoAccountsWithOnlyBlockedAssignments. This setting is disabled by default and applies only when the account's sole reason is AutoAccount and no non-blocked assignment remains.

Pending Update (PendingUpdate)

The assignment is pending being updated in the target system. An update could, for example, have the purpose of changing the disabled state of an account in the target system.

For an assignment to be Pending Update, one or more of the following must be true:

• The value of a mapped attribute relevant for provisioning differs between Omada Identity and the target system representation in the Warehouse or a recent provisioning claim. Attribute reconciliation must be enabled on the resource type.

• The value of an unmapped attribute relevant for provisioning has changed in Omada Identity compared with the previous computation, and attribute reconciliation is enabled on the resource type.

• The disabled flag of the assignment differs between Omada Identity and the target system.

• The assignment is an account that would otherwise be Pending Deprovisioning because it is managed and does not have a desired state reason, but because the system does not support account deletion and the account is enabled in the target system, the status instead becomes Pending Update.

• A provisioning claim was created while attribute reconciliation was enabled, and no newer actual state has since been received through an import. The claim is therefore treated as the most recent known state of the provisioning attributes, even if attribute reconciliation is no longer enabled for the resource type.

  • If the current desired attribute values differ from those recorded in the claim, the assignment enters the Pending Update state. This state is resolved when an import provides a newer actual state or when the claim expires and a new calculation is performed.
  info

  An account may enter Pending Update state even when it is not managed by Omada Identity and has no desired-state reason. This can occur when the assignment originates from an imported account (Actual Direct reason) and the disabled state calculated by RoPE differs from the disabled state reported by the target system. In this situation, Omada Identity creates a Pending Update task to synchronize the disabled state.

  Assignment policy filters only affect whether a policy-based desired-state reason is added. They do not prevent RoPE from calculating assignments that originate from imported accounts and have an Actual Direct reason.

Attribute and state comparison when both desired and actual state exist

When an assignment has both a desired state reason, for example a direct assignment, and an actual state reason, for example a Warehouse record or an active provisioning claim, Omada Identity compares the current desired values against the known actual values.

If a discrepancy is found, the assignment enters the Pending Update state.

The source of the actual values and which attributes are compared depend on the configuration of the resource type and whether a recent provisioning claim exists.

Source of actual values

Source	When it applies
Active provisioning claim	OPS has completed a provisioning task, but the Warehouse has not yet confirmed the result via import. The claim is the most recent known state.
Warehouse (import)	The Warehouse has a record for the assignment that is more recent than any provisioning claim.

Attributes compared against the actual state

The set of attributes compared depends on the source and the resource type configuration.

When the actual state comes from the Warehouse

When the actual state comes from the Warehouse and Reconcile on attribute level is enabled, only the Reconciliation attributes are compared.

These are determined by the resource type configuration in the following order of precedence:

1. If a Reconciliation attributes map is defined on the resource type using the RECONCILATTRSMAP property, only the attributes listed in that map are compared against the Warehouse.
2. If no map is defined but a Provisioning attribute set is specified using the SYNCPROVATTRS property, all attributes in the provisioning attribute set are treated as reconciliation attributes.
3. If neither is defined, all attributes in the Assignment attribute set, defined by the ATTRIBSETREF property, are treated as reconciliation attributes.

Example

A resource type has RECONCILATTRSMAP configured with FIRSTNAME=givenName;LASTNAME=sn.

Only the FIRSTNAME and LASTNAME values of the assignment are compared with the corresponding givenName and sn values from the Warehouse. Changes to other provisioning attributes do not trigger Pending Update from the Warehouse comparison.

When the actual state comes from an active provisioning claim

All provisioning-relevant attributes, as defined by SYNCPROVATTRS, or all attributes if it is not set, are tracked in the claim at provisioning time, along with the account name and the disabled flag.

The following comparisons are made:

• Reconciliation attributes — compared against the values recorded in the claim at provisioning time.
• Disabled flag — compared against the value recorded in the claim.
• Account name — for account assignments, account name changes are always detected. For permission assignments, the behavior depends on the Reconcile account name setting:
  • If Reconcile account name is enabled, account name changes are explicitly detected.
  • If Reconcile account name is disabled, account name changes on permission assignments are still detected when a claim exists, because the claim records the account name as part of the assignment's provisioning fingerprint.
• Other provisioning attributes not included in the Reconciliation attributes map — compared against the previous calculation.

Example: Reconciliation attribute change

An account assignment has VALIDTO in the Reconciliation attributes map. A role change pushes the access end date forward. When Omada Identity recalculates, the new VALIDTO differs from the value in the Warehouse record, resulting in Pending Update.

Example: Account name change on an account assignment

An identity's account name changes because the IDENTITYID attribute is updated from jsmith to john.smith. The account assignment records this change regardless of whether the actual state comes from a claim or the Warehouse, resulting in Pending Update.

Example: Account name change on a permission assignment without Reconcile account name

The same identity rename causes the permission's effective account name to change from jsmith to john.smith.

Even though Reconcile account name is not enabled on the resource type, the change is detected because the claim recorded the account name at provisioning time, resulting in Pending Update.

Example: Non-reconciliation provisioning attribute change

An attribute is part of the Provisioning attribute set but not in the Reconciliation attributes map. Its value changes in Omada Identity.

Since it is not compared against the Warehouse, Pending Update is triggered by comparing the attribute against the previous Omada Identity calculation.

Pending Deprovisioning (PendingDeprov)

The assignment is pending being deprovisioned, or deleted, in the target system.

For an assignment to be Pending Deprovisioning, all the following must be true:

• The assignment must be represented in the Warehouse, or a provisioning claim for it must exist.
• The assignment must not depend on, and wait for, another assignment to be deprovisioned first.
• If the assignment is an account, then the system must support deletion of accounts.

Also, the following may be true:

• The assignment is for a permission, and it is disabled in Omada Identity.
• The assignment is an account, and it has been removed in a survey.
• The assignment is managed, and it does not have a desired state reason.
• The assignment is for an application role or enterprise role, and one or more of its child resources is Pending Deprovisioning.

OK (Pending Confirmation) (OKPendingConfirmation)

No provisioning, deprovisioning, or update needs to take place. However, we have not yet received confirmation from the Warehouse that it has taken place.

For an assignment to be OK (Pending Confirmation):

• Omada Identity has concluded that no provisioning, deprovisioning, or update needs to take place in the target system. However, RoPE has not yet received confirmation from the Warehouse that it has taken place.
• Omada Identity is configured to await fulfillment confirmation from the Warehouse.
• If the assignment is for an application role or enterprise role, one or more of its child resources is OK (Pending Confirmation).

note

This state can be skipped in the flow under certain circumstances.

For example, if provisioning is disabled for a resource data object, the provisioning status is set directly to OK.

If a provisioning task fails because the object already exists in the target system, the status can be set to Failed before changing to OK after the next import.

Relayed (Relayed)

Provisioning has been relayed to an external ITSM or similar system. Omada Identity is awaiting confirmation that the provisioning has been completed.

For an assignment to be Relayed:

• The assignment is not represented in the Warehouse.
• The assignment must not depend on, and wait for, another assignment to be provisioned first.
• The assignment is picked up by the relay connector and sent to an external system for provisioning.

Failed (Failed)

Provisioning could not be completed due to, for example, a licensing issue or long-lasting network outage.

For the assignment to be Failed:

• The assignment is picked up by the relay connector and sent to an external system for provisioning.

Also, one or more of the following must be true:

• The external provisioning system refused to perform the assignment.
• Omada Identity has not received confirmation from the external provisioning system that the assignment was completed.
• After several retries, OPS was unable to perform the assignment.

Delayed Provisioning (DelayedProv)

The assignment should be provisioned, but provisioning is delayed because another assignment needs to be provisioned first.

For an assignment to be Delayed Provisioning, the following must be true:

• The assignment meets the requirements for the Pending Provisioning status.

Also, one or more of the following must be true:

• The assignment is for a permission resource, and it belongs to an account that has not yet been provisioned.
• The assignment is for a resource that depends on the provisioning of another resource.

Delayed Deprovisioning (DelayedDeprov)

The assignment should be deprovisioned, but deprovisioning is delayed because another assignment needs to be deprovisioned first.

For an assignment to be Delayed Deprovisioning, all the following must be true:

• The assignment meets the requirements for the Pending Deprovisioning status.
• The assignment is for a resource that depends on the deprovisioning of another resource.

Pending Deprovisioning Confirmation (PendingDeprovConfirmation)

The assignment is claimed to have been deprovisioned, or deleted, but Omada Identity has not yet received confirmation of it from the Warehouse.

For an assignment to be Pending Deprovisioning Confirmation, all the following must be true:

• A deprovisioning claim has been issued.
• It has not yet been confirmed by a Warehouse import that the assignment has been deprovisioned in the target system.

Deprovisioning Failed (DeprovFailed)

Deprovisioning could not be completed due to, for example, a long-lasting network outage.

For an assignment to be Deprovisioning Failed, all the following must be true:

• The assignment must be represented in the Warehouse, or a provisioning claim for it must exist.
• The assignment must not depend on, and wait for, another assignment to be deprovisioned first.
• If the assignment is an account, the system must support deletion of accounts.

Also, one of the following must be true:

• Omada Identity has not received confirmation from the external provisioning system that the deprovisioning was completed.
• After several retries, OPS was unable to perform deprovisioning.

Moreover, the following may be true:

• The assignment is for a permission, and it is disabled in Omada Identity.
• The assignment is an account, and it has been removed in a survey.
• The assignment is managed, and it does not have a desired state reason.

? (NotSet)

This provisioning status value is used only temporarily during computation and should never be assigned to an assignment.

Factors affecting the provisioning status

Several configuration settings affect the computation of the provisioning status of an assignment. Click each factor to learn how it affects the provisioning status.

Enable provisioning on the system level

On a System data object, the type of provisioning can be selected for account assignments and permission assignments.

If the provisioning type is None, the provisioning status for assignments to resources belonging to the system will always be OK.

System support for deletion of accounts

On a System data object, it can be indicated that the target system does not support deletion of accounts.

If the Account deletion unsupported option is enabled, the provisioning status for assignments to resources belonging to the system will never be Pending Deprovisioning.

Attribute level reconciliation

On a Resource Type data object, it can be configured to Reconcile on attribute level. The setting is used together with the Reconciliation attributes map setting.

When reconciliation is enabled, RoPE compares the relevant target-system attribute values, as represented in the Omada Identity Warehouse or a provisioning claim, with the desired attribute values in Omada Identity.

If there is a discrepancy, the assignment can receive the Pending Update status.

For details about which attributes are compared and how the comparison differs between Warehouse records and active provisioning claims, see Attribute and state comparison when both desired and actual state exist.

Managed vs. unmanaged assignments

RoPE considers an assignment managed if either:

• It is indicated on the resource type that all assignments are managed, or
• The assignment has, or used to have in any previous calculation, at least one desired state assignment reason.

Being managed means that an assignment will be deprovisioned if, at some point, it has no desired state reason.

Omit provisioning and dependent provisioning on individual resources

On a Resource data object, it can be configured that assignments to the resource should never be provisioned by selecting the Skip provisioning checkbox.

When selected, the provisioning status for assignments to the resource will always be OK.

This configuration may be useful, for example, in the case of Domain Users within an Active Directory system that is managed by Active Directory itself.

Resource data objects and Resource folder data objects include a setting called Provisioning depends on that refers to a resource. CRAs to the first resource depend on the provisioning of the referred resource.

CRAs whose provisioning depends on another resource are not provisioned until the referred resource has been provisioned.

If both the resource data object and the resource folder data object refer to a resource in the Provisioning depends on property, the value of the resource data object overrides the value of the Resource folder.

Await fulfillment confirmation from the Warehouse?

A customer setting controls whether RoPE should await fulfillment confirmation from the Warehouse before setting the provisioning status to OK.

If so, the provisioning status for an assignment will be OK (Pending Confirmation) until a Warehouse import confirms fulfillment.

Claim expiration times

On a System data object, the provisioning claim expiration time can be set for account assignments and permission assignments.

This value defines how long RoPE waits before issuing a new provisioning task to mitigate differences between the actual and desired states, that is, before RoPE performs reconciliation.

If a system uses Relayed provisioning, the provisioning claim expiration time should be set to a number of days higher than the default two days, for example 10 days, to allow the external provisioning system to complete the task and send a response to Omada Identity.

If the provisioning claim has the status Failed, a separate expiration time should be set. By default, failed provisioning claims should never expire, which means the time should be set to -1.

You can also set the value -1 for non-failed provisioning claims so that the claim never expires. The value -1 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).

info

The provisioning status for an application role or enterprise role assignment is affected by the provisioning status of its child resource assignments:

• If the role has a child resource assignment with the status Pending Provisioning, and the role assignment is not disabled, the status of the role becomes Pending Provisioning.
• Otherwise, if the role has a child resource assignment with the status Pending Deprovisioning, and the role assignment is disabled, the status of the role becomes Pending Deprovisioning.
• Otherwise, if the role has a child resource assignment with the status OK (Pending Confirmation), the status of the role becomes OK (Pending Confirmation).

Viewing the provisioning status of an assignment

The provisioning status of an assignment can be inspected in the Assignments explorer in the Omada Identity portal.

The status is stored in the PROVISSTATUS attribute. PROVISSTATUS has a value when the ProvisioningStatusCalculator RoPE extension is applied, which it is by default.

Even if the extension is not applied, RoPE still calculates provisioning status internally when determining whether provisioning tasks should be created.

For general information about the Assignments explorer, including the Delta, Differences, and Messages nodes, see Inspection of calculation results.

Identifying what triggered Pending Update

When an assignment enters the Pending Update state, its calculation results can help identify the difference that caused the status change.

Review the assignment's Messages and, where relevant, its Differences information:

• Messages indicate conditions detected while RoPE processed the assignment, including discrepancies between the desired state in Omada Identity and the known actual state.
• Differences show changes between the current and previous calculation and can help identify provisioning-relevant attribute changes.

Messages related to Pending Update can include:

• Attribute values differ in OIS and target system — one or more reconciliation attribute values differ between Omada Identity and the known actual state from the Warehouse or an active provisioning claim.
• Disabled state differs in OIS and target system — the disabled flag in Omada Identity does not match the known actual state.
• Account name/type differs in OIS and target system — the account name or account type differs from the known actual state.

tip

Use the calculation messages together with the assignment differences to determine why the assignment is waiting to be updated in the target system.

For general information about inspecting calculation results, see Inspection of calculation results.