Role with type Rapidsetup Birthright roles didn't reflected to identity

IdentityIQ (IIQ) IIQ Discussion and Questions
,
1

Hi Community,

  • i just explored about the role & role with type birthright roles in sailpoint IIQ 8.4 so i just created one IT role and just added some entitlements and then attached it to one business role by match list keeping Department = “Accounting” so it worked properly after doing refresh identity Cube by keeping check box enabled of Provision assignments, Refresh assigned, detected roles and promote additional entitlements then all the identity’s having department as Accounting have relected with the Bussiness Role i created

  • next created one more role with type Rapidsetup Birtright and added some entitlements and kept the match list as Department = Information Technology

  • created 2 new entries with one department Information Technology & Accounting the identity having Accounting got its role but the identity having Information Technology didnt refelected the role

  • see the attached images for better understanding data added in flat file is
    Name,FirstName,LastName,Department,EmployeeNo,Email,NetworkID,manager,JoiningDate,Inactive
    Aobert Brown,Aobert,Brown,Information Technology,1Aa2a3a,Aobert.Brown@eshiam.com,Aobert.Brown,1a2a,FALSE
    Cobert Brown,Cobert,Brown,Accounting,1Aa2Aa3a,Cobert.Brown@eshiam.com,Cobert.Brown,1a2a,FALSE

image
image1875×557 33.3 KB

image
image967×878 40 KB

image
image1862×720 43 KB

so if you observe the identity’s Cobert Brown, Aobert Brown the Cobert Brown with department Accounting got the role but Aobert Brown with department Information Technology didt got the role see the role images provided below

image
image1225×851 42.5 KB

image
image1753×837 35.6 KB

2

The behavior you’re seeing is expected because rapidSetupBirthright roles are assigned through the Rapid Setup Joiner/Mover processing, not just by running Refresh Identity Cubes.
First verify that Rapid Setup → Joiner Processing is enabled globally and that rapidSetupBirthright is listed under Role Types to Treat as Rapid Setup Birthright Roles.
For your flat-file application, also enable Automatically Start Joiner Processing for Newly Created Identities, so a newly aggregated identity such as Aobert actually enters the Rapid Setup Joiner workflow.
If Aobert was already created before Joiner processing was enabled, another Identity Refresh alone will not necessarily assign the RapidSetup role; you need to trigger the appropriate Joiner/Mover processing so the birthright assignment rule is evaluated.
So I would check the Rapid Setup configuration and whether the Joiner workflow actually ran for Aobert before changing the role or its Department match condition.

3

Hi @Harsha_Vardhan_Bondi ,Adding to @amrdodani 's point, I would also check whether Aobert actually went through the Rapid Setup Joiner processing.

Could you check Aobert’s Identity XML in Debug and see whether there is a rapidSetupProcessingState attribute/value present? Also check the workflow cases to confirm whether the Rapid Setup Joiner workflow was launched when the identity was created.

That should help determine whether the issue is with the role assignment itself or whether Aobert never entered the Rapid Setup Joiner processing in the first place.

4

@Harsha_Vardhan_Bondi -

Building on what’s already been flagged: rapidSetupBirthright assignment isn’t something a later Identity Refresh will backfill, even once Joiner is configured correctly. The assignment happens as a step inside the RapidSetup Joiner (or Mover) business process itself. The standard rule-based assigner that “Refresh Identity Cube → Provision assignments” invokes doesn’t evaluate rapidSetupBirthright roles at all unless that’s been separately enabled for the role. If Cobert’s role is a normal (non-RapidSetup) birthright role rather than rapidSetupBirthright, that would explain the split you’re seeing: two roles, two different assignment mechanisms, and refresh only reaches one of them.

So once you’ve confirmed Joiner Processing is on, IT is listed under Role Types to Treat as Rapid Setup Birthright Roles, and Aobert’s account was aggregated after both were true, you still need to re-trigger Joiner for Aobert specifically rather than just refreshing again. Two ways to do that without deleting and re-adding the identity:

  1. Reset Aobert’s rapidSetupProcessingState attribute from processed back to needed, then re-run the source aggregation. RapidSetup reads that attribute to decide whether an identity still needs Joiner/Mover processing, so flipping it forces re-evaluation on the next run:
identity.setAttribute("rapidSetupProcessingState", "needed");
context.saveObject(identity);
context.commitTransaction();
  1. Or go through Mover instead: re-aggregate the source with “Disable Optimization of Unchanged Accounts” enabled so the account gets re-diffed even with no source-side change, and make sure your Mover trigger filter would actually catch a department = IT identity.

There’s also a blunter fix mentioned elsewhere: unchecking “No automatic assignment with rule” on the role lets the standard assigner pick up rapidSetupBirthright roles during ordinary Identity Refresh too. That changes behavior for every identity with that role type, not just Aobert, so treat it as a deliberate design decision rather than a quick unblock.

None of this (the processing-state attribute, that assignment checkbox) shows up in the public Joiner/Mover Configuration doc pages, only in community threads, so verify it in a non-prod environment before running it against real identities.

Docs: Rapid Setup Joiner Overview, Joiner Configuration