Understanding how assignmentIds are added or removed, and the criteria used for Detected IT Roles of an identity

IdentityIQ (IIQ) IIQ Discussion and Questions
,
1

We have an RBAC structure in place where Business Roles include permitted IT roles. At the identity level, there are also detected IT roles that are not assigned through SailPoint.

Our objective is the following: if a detected IT role is defined as a permitted role within a Business Role (at the bundle level), and the Business Role is assigned to the identity, then the assignment ID from the Business Role(roleassignment) should be reflected on the detected IT role.
To achieve this, we attempted to link or assign the IT role as a permitted role within the Business Role for that identity
(RoleAssignment – Business Role → PermittedRoleAssignments – IT Role).

As a result, the assignment IDs were updated for the detected IT roles for some users. However, for other identities, this behavior is not working as expected.
We would like to better understand the following:

  1. How are assignment IDs added to detected roles at the identity level?
  2. What validations or checks occur during this process?
  3. What conditions must be met for the assignment ID (from the Business Role assignment) to be associated with a detected IT role?
  4. Does the Role Target of the Business Role play a significant role in this behavior
  5. Additionally, we have observed that in some cases, the permitted role assignment gets automatically removed. We would like to understand the underlying or implicit functionality behind this behavior, as it is not clearly documented in SailPoint documentation or community resources.
2

hi @ramireddy The assignment IDs on detected IT roles are derived at evaluation time, not persistently assigned.

How it works

  • IIQ never directly assigns a roleAssignmentId to a detected IT role.

  • During role evaluation, if:

    • A Business Role is actively assigned to the identity, and

    • The detected IT role exactly matches a Permitted IT Role of that Business Role, and

    • All constraints (targets, dates, status) are satisfied
      → IIQ logically associates the Business Role’s assignmentId to that IT role.

Why it’s inconsistent

  • The association is recalculated, not stored.

  • It fails if any condition differs per identity (timing, detection source, multiple BRs, conflicts, expired assignments, etc.).

Role Target impact

  • Yes, it’s critical.
    If the detected IT role falls outside the Business Role’s Role Target, IIQ will silently drop the permitted-role association.

Why permitted role assignments disappear

  • IT role no longer detected

  • Identity no longer meets role target

  • BR assignment becomes invalid

  • Access is justified via another role path
    This is expected—permitted roles are justification metadata, not hard bindings.

Takeaway: Detected roles are descriptive; assigned roles are authoritative.
If you need a permanent linkage, don’t rely on detection use explicit assignment or custom rule logic.

3

@ramireddy Business Roles and Required Roles goes together that’s why they always have the same assignmentIds. But in case of permitted IT roles, you can assign them afterwards, and removing them also doesn’t cause any sync issues. So, IIQ assign a different assignment id to the detected role.

May i know why do you want to keep the assignment Ids same in case of required and permitted IT roles?