Pre-validity and post-validity
If RoPE calculates a CRA and the current time is outside the validity period of the CRA, that is, before the validity period starts or after the validity period ends, the CRA is normally disregarded, so that it is not included in the calculation result.
However, RoPE has a concept of Pre-validity and Post-validity. RoPE includes a CRA in the calculation result a number of days before it becomes valid and a number of days after it stops being valid, but it is marked as disabled.
This allows for provisioning account assignments before a user's start date, and mitigation of incorrect HR termination triggers. It also ensures that accounts are not deleted on the last working day of an identity.
If it is the identity itself that is either pre-valid or post-valid, RoPE will extend the validity period of Calculated Permission Resource Assignments (CPRA). In the extended period before and after the validity period, the identity is not marked as disabled. This is to prevent the permission assignments from being deprovisioned and to allow that permissions can get provisioned during the pre-validity period. This is safe to do since the accounts for which the permissions are granted will always be disabled.
The pre-validity period is by default three (3) days for all CRAs of all types. It can be configured in the customer settings, as shown below (path: Setup > Administration > More > Customer settings).
The post-validity is by default zero (0) days. It can be configured per resource type in the Edit Resource Type dialog, as shown below. If you do not enter any value in the field, it is interpreted as zero.
Pre-validity and post-validity scenarios
The pre- and post-validity functionality makes it possible to extend the validity periods for account assignments (CARAs) and permission assignments (CPRAs). Account assignments can be provisioned in a disabled state outside the validity period of the identity, and permission assignments can remain provisioned beyond the validity period of the identity.
This means that accounts can be provisioned for a given identity a set number of days before the identity is enabled, and that permissions are not deprovisioned for a set number of days after the identity is disabled or locked.
The timeline below illustrates an example of the pre-validity and post-validity periods.
Pre-validity
Pre-validity allows the AD Account assignment to be created before the date on which the identity and account become active. During this pre-validity period, the assignment is disabled and becomes active on the valid from date. At the same time, the calculated permission assignment for the AD Group can only be provisioned after the identity is enabled.
Post-validity
In the case of post-validity, the AD Account assignment is disabled at the same moment the identity is disabled or locked, unless another assignment reason with post-validity keeps the account provisioned. However, the CPRA for the AD Groups is not disabled, and this permission assignment is deprovisioned at the end of the post-validity period.
Account assignments (CARAs) do not independently respect the account type post-validity setting.
A CARA will remain provisioned beyond the identity's validity period only if there is another assignment reason (such as a permission, role, or policy) that depends on the account and has post-validity configured.
When that permission or other assignment reason exits its post-validity window, both the CPRA and the CARA are then deprovisioned.
Post‑validity behavior for direct assignments
When a resource type defines a post-validity period, this behavior applies to direct resource assignments in the same way as it does to role-based assignments. This includes scenarios where a direct assignment is explicitly removed, such as through recertification, manual revocation, or validity expiration.
Post-validity does not delay deprovisioning. Permissions are removed from the target system immediately when the assignment ends. Post-validity affects visibility and compliance calculations only.
When a direct assignment reaches its Valid To date or is removed, the assignment transitions to an obsolete state.
The following table presents the lifecycle of a direct assignment with post-validity:
| Stage | Description |
|---|---|
| 1. Assignment expires or is revoked | The direct assignment becomes obsolete. RoPE marks it as disabled, and the provisioning engine removes the corresponding permission from the target system. |
| 2. Post-validity window | RoPE continues to include the obsolete assignment in its calculations. In the identity’s Permissions view, the assignment remains visible, appears as disabled, shows Compliance State as None, and retains a (Direct) reason, although it no longer represents an active desired state. The assignment no longer exists in the actual state. |
| 3. Post-validity ends | The assignment is removed from RoPE calculations and disappears completely from the UI and all assignment grids. |
This behavior applies when:
-
A direct assignment reaches its Valid To date
-
A direct assignment is revoked during recertification
-
A direct assignment is revoked manually
-
The identity itself remains active
During the post-validity period, RoPE retains a disabled assignment object to ensure:
-
consistency in compliance calculations
-
predictable assignment lifecycle handling
Although the permission has already been removed from the target system, the calculated assignment remains visible in Omada for the duration defined on the resource type.
A resource “Permission A” defines a post-validity period of 60 days.
-
2025-11-21 – The user loses the direct assignment
- The permission is removed from the target system immediately
-
Until 2026-01-20, Omada shows the disabled direct assignment with Compliance State as None
-
2026-01-21 – the assignment disappears from the UI and is no longer included in RoPE calculations