In the lower environment we created a Role via the AI tool and added an Access Profile - with entitlement - to the Role. We enabled the Role but not the Access Profile assigned to the Role. We noticed the Role still gets assigned to the identity.
What is the purpose of enabling the Access Profile in a Role? Is it just to make the Access Profile requestable?
Does an Access Profile assigned to a Role need to be enabled along with the Role in order to render entitlement assignment via the Role?
I did some testing because I was curious about this behavior you pointed out. In short, a Disabled Access Profile will not be added to a user through Role provisioning. Only the Role will be assigned to the user. If the Access Profile is enabled, assigned to a user through a Role, then disabled, the Access Profile is removed from the user but the entitlements are not removed. So yes, an Access Profile assigned to a Role needs to be enabled along with the Role for Access Profile and Entitlement assignment to occur.
Here are some more details about the testing I did.
I created a Role and an Access Profile. I was able to add the Disabled Access Profile to the Role. I then assigned the Role to a test user that does already have the access in the test Access Profile using the Identity List assignment option. I then enabled the Role, applied changes and confirmed the test user was then assigned to the role when the role refresh was completed (Access Profile still Disabled at this point). I confirmed the test user was NOT assigned the Access Profile or the corresponding entitlement, only the Role was assigned.
I then enabled the Access Profile and ran another refresh. The Access Profile and entitlement were added to the user.
Finally, I Disabled the Access Profile again and ran another refresh. The Access Profile was removed from the user, but the entitlement was not removed. This is consistent with the Disabling an Access Profile documentation.