I’d like to hear your thoughts on the advantages and benefits of RapidSetup Birthright.
I’m wondering why SailPoint implemented this feature, as business roles with assignment rules work very well, and I don’t see the point of using RapidSetup Birthright.
It’s even worse because in the case of a new RapidSetup birthright being added, if the relevant identities have already passed the joiner event, the role is not assigned!!
Another case is when updating the assignment condition of a RapidSetup birthright; it is not automatically unassigned from the relevant identities because the role is assigned via RapidSetup and is only unassigned during a Mover RapidSetup event. (see Assign new Rapid Setup Birthright roles / RapidSetup Leaver Negative Role Assignment …)
All these problems do not exist in the case of business roles. A refresh is enough to calculate the changes.
In our work, we found that RapidSetup is best suited for standardized, out-of-the-box use cases, primarily helpful for quick demos, beginner learning, or initial proof-of-concept environments in IdentityIQ. It’s a great way for newcomers to get familiar with the platform and understand basic provisioning flows.
However, it quickly hits limitations when trying to adapt to complex or evolving business requirements.
Because of this, we don’t use RapidSetup for our IIQ instances during client implementations. Instead, we rely on our team’s deep experience in configuring SailPoint to ensure a scalable, policy-driven approach aligned with organizational needs.
In short, RapidSetup is a helpful starting point, but not a sustainable solution for enterprise-grade IAM design.
Your points are all totally valid. From my perspective there are two things that can be seen as reasons for potentially using using RapidSetup Birthright Roles:
From an Identity Request perspective tied to the Joiner Workflow event, you are able to see the birthright roles that were assigned and the resulting accounts that were created/updated. When using normal business roles which are automatically assigned during refresh the proper arguments, this happens behind the scenes and you need to track down audit events or provisioning events to figure out when and why it happened. It also may make timing the assignment of these roles and subsequent provisioning a bit easier rather than using complex assignment rules on business roles (i.e. 1 week before employee start date)
These types of roles would on be used for the most core birthright access to be provisioned. For example, if every AD account requires a group to allow access to the org’s VPN. You also add additional access at a later point which would be provisioned as long as identities already have the rapidsetup birthright role assigned
Thank you very much for your point of view. It confirms my understanding of RapidSetup Birthright roles.
This is important to me because I haven’t found any documentation detailing the benefits of these types of roles.
I also noticed that RapidSetup’s Birthright roles contain the entitlements directly within the role (like IT roles) and don’t require a relationship between the business role and the IT role. So this simplifies the approach a bit.