Role Assignment with Multiple Accounts not working as expected

Identity Security Cloud (ISC) ISC Discussion and Questions
, , ,
1

There are a couple similar questions but no solution seems to have been identified so far. E.g.,

BACKGROUND:

  • A user has 2 accounts on Active Directory (1 active, 1 disabled)
  • A user has 2 accounts on a BusinessApplication (1 active, 1 disabled)
  • BusinessApplication has an access profile, enabled for request, and assignment criteria is set up to automatically assign access to the active account.
  • A role is configured, with the following settings:
    • Role has 1 access profile, called ‘AD SSO Access Profile for Business Application’
    • ‘AD SSO… Application’ access profile is configured to assign an entitlement, with the multiple account options configured to select the active Active Directory account
    • Assignment criteria is configured so that the role is assigned if…
      • AD account is active
      • Business Application account is active
      • Identity is active

ISSUE

  • The role is not being assigned to the identity, even though with the active accounts, all requirements for the assignment criteria have been met.

My assumption is that ISC is taking information from the inactive AD record or Business App record and not assigning the role, even though there is both an Active AD account and active Business App account.

Any thoughts?

Thanks,

Margo

2

What does your assignment logic look like for the role where you are checking for the active accounts?

It sounds plausible that you are running into this issue for the reason that you mention, and that the role assignment may not be properly handling multiple accounts.

3

Hi Geoff, the assignment criteria on the role is below.

Note that both accounts on AD meet the ‘mail’ criteria. The identity is active, and on the source, 1 account has ‘Is Active’=true and one is false

image
image1432×1136 95.7 KB

4

Couple follow up questions:

  • Does this work if the user only has 1 active account of each type?
  • Does this work if the user has 2 active accounts of 1 type, and 1 active account of the other type?
  • If the user has multiple accounts of each type, does switching which one is active change it?

I have not run into this situation before, but I do suspect that it could be getting the first inactive account and dropping out without checking the other. The documentation is also not clear on this situation, only stating that the Account Profile will handle assigning to the correct account.

If no one else responds with concrete answers, you may want to discuss this with your CSM or PS.

The only other option I can see if to use a IdentityAttribute that checks to see if they have an active account on both Sources and then holds a value (ie true) that can then be used in the Role Assignment. Not ideal, but may work for you.

5

Hi Geoff,

  • Yes, the role assignment works with the user has 1 active account of each type
  • No, we must remove the business app and AD account for this to work
  • Unfortunately can’t simulate this one as it is PROD - but my assumption is that if the lower id is the active record (the ‘first’ one SailPoint sees) then it would probably work.

I’ll open a ticket with support and update this ticket with any results for future use by anyone else experiencing the same issue

6

Based on this, I would guess that this currently doesn’t work. Let us know what the results of the ticket are.

7

I generally use segmentation using multiple accounts.

If you have multiple personas, such as: employee, student, privileged; etc. I would have a separate connector for each persona and use filtering so that the connector only pulls for the given persons for that specific source.

8

For anyone viewing this ticket - at this time (Feb 2026), SailPoint engineering has identified this to be by design. I will be opening a SailPoint Ideas Portal ticket for this, as this seems like a flaw in the design - in my view, what is the point in role assignment criteria and account selection configuration if it will just be ignored if there are multiple accounts to take the account that was most recently correlated :slight_smile:

The response from SailPoint is below - I have opened an ideas ticket at https://ideas.sailpoint.com/ideas/GOV-I-5001 and encourage anyone who runs into the same issue (or agrees that this design is flawed) to upvote the idea

-—

Please note that during the role criteria evaluation - the account which has the latest/ recent correlation to the identity gets picked up for the role assignment and this is by design and thats’ how the product works.

In this scenario, since there are 2 accounts present and upon reviewing the logs and identity, it was observed that the disabled AD account is the one which was correlated last or recently and hence, when the criteria is being evaluated , the disabled account is getting picked but since the criteria is not getting matched, the role is not getting assigned.

However, when you are trying to remove the disabled account temporarily - the only account which remains is the enabled one and hence, the role gets assigned.

-—

To overcome this - If you want to use the account attribute value as the role criteria, then, you must be sure that the most recently correlated account is always the one with the “correct” value.

For the existing identities, you can fix this by removing the enabled account from the identity and then re-aggregating it. After re-aggregation, that enabled account becomes the most recently correlated account, and the role will then be applied.

The other option is to map the value to an identity attribute. With a rule you can select the “enabled” account value for the identity attribute value. Then, use the identity attribute as the role membership criteria.

1 Like
9

LoL…by design that lacks holistic considerations of the reality that the product is meant to serve. This “most recently correlated” logic is an internal product behaviour that means nothing anywhere else. Design that lacks synergy even within itself.

1 Like
10

I agree - if you’re aligned, I would encourage you to upvote the idea at https://ideas.sailpoint.com/ideas/GOV-I-5001 to ensure that it gets attention sooner

1 Like
11

On a remotely related note…I’m triggered by this type of “By design” responses:

2 Likes
12

This “by design” explanation feels fundamentally flawed. From an IAM perspective, role assignment criteria should evaluate all correlated accounts to determine eligibility, not just the most recently correlated one. The whole purpose of having multiple account selection options is to give SailPoint admins control over which account is used for access decisions. If the product ignores that configuration and defaults to a single account, it undermines the principle of accurate and comprehensive role evaluation.

This behavior not only creates unnecessary complexity but also forces administrators into error prone workarounds. A true fix would ensure that identities meeting the defined criteria consistently receive the intended role assignment, regardless of correlation order. Hopefully, engineering and product teams will revisit this design choice, as it contradicts the core IAM principle of reliable and predictable access governance.

1 Like
13

Instead os using account attribute in assignment criteria would it be possible to shift to an identity attribute ( Using transform we can check active account condition and populate some value ) ?

Using identity attribute in assignment criteria would solve the problem here.

14

While technically possible, creating identity attributes to capture whether 1/2 accounts are enabled or disabled is not a sustainable design choice - the more apps you onboard, you can’t just keep creating identity attributes to house the status of specific account combinations. In a pinch it could work, but I’d caution against it because you might end up down a path with 15, 20+ identity attributes just to store account status combinations if you go that route

15

I completely agree with you, however that was intended as an interim solution untill SailPoint introduces that capability.

1 Like