I’ll try to respond to a couple more of your questions at once:
Will the ServiceNow request catalog integration follow suit with this new feature?
Yes, our ServiceNow Catalog integration team is already working on implementing this feature in their integration.
...you seem to be touting that it addresses the specific situation of an IT user having multiple accounts on the same source. However, I’m being told that the new functionality / new API is going to make it possible for me to send Account-Specific access request payloads to add an Entitlement. Is this right?
I don’t mean to suggest that this only applies to IT users - it’s just that we know they are among the most common users who do have multiple accounts on a source. Yes. This new functionality does allow you to use our API to send account-specific access request payloads to add an entitlement.
Also, the API documentation has been updated to reflect the new payload option. Examine the requestedForWithRequestedItems section of the Request payload in the create-access-request | SailPoint Developer Community documentation.
If you need to force the account association for the type of entitlement, I would continue to model the multiple accounts as different sources. Tis allows you to maintain that forced association.
Take a common AD example:
AD Source 1 (Main Users Source)
Scoped to aggergate accounts from all OUs EXCEPT the Admin Accounts OU
AD Source 2 (Admin Accounts)
Scoped to aggregate only from the Admin Accounts OU
Also only scope to groups in the “Local Admins” OU.
This case maintains that you DONT want normal users to request “Local Admin” AD groups on there normal account. This is common for compliance reasons, and therefor needs to be forced by a technical guard. Rather than a requester accidentally requesting for the wrong account, and an approver not catching the difference.
Password is a different topic entirely, and one in which I am not an expert. This release was specifically about access requests for users who have more than one account on a source. Please open this question as a separate discussion topic so the right people with expertise and knowledge in the password domain can speak to it.