Hi @Kurt_Ramsey, no, the roles schema removal prevents the retrieval of associated role details. No extra processing is conducted for roles, and the source does not consolidate them.
I am uncertain about the configuration specifics for both the types of sources in your environment. It would be greatly beneficial if you could provide the statistics and configuration details through a support ticket. Rest assured, we will promptly investigate this issue.
I think @eabedrapo1 idea is really good, and this should be part of IdentityNow source, and not a separate source.
I still dont see the point of having ISC roles as Entitlements, what benefit does this have?
Governance groups and User Levels are really good though.
Another really good entitlement would be PATs (user personal access tokens). Being able to perform a certification on user tokens, or marking tokens that have scopes:all as privileged, would be super helpful.
Hi @jrossicare, thanks for sharing your interest for managing PATs (user personal access tokens) as an entitlement. We will check on that as per the upcoming roadmap.
For roles, I already mentioned in one of my earlier comment that we considered the âRolesâ based on the feedback from few of our customers where customer wants the visibility for the associated Roles as a part of the entitlements for the accounts.
I agree that it might not be required for everyone and âjust in caseâ kind of deal. If it is not required for your use cases and requirement, it can be removed from the account schema (Roles) and as well as from the Group attributes.
After removing the roles, you can continue to use the connector for managing Governance groups and User Levels.
Hi @tdelorge-mmb, once you aggregate Governance Groups as entitlement, there will be ID, name and description. ânameâ is the display attribute and âidâ is the native identity (unique identifier). So, after entitlement aggregation, it will be displayed as name of the Governance Group.
I am working with this connector, looking into it to potentially manage userlevels on IDN. We have more than 100k identities and a full aggregation will take hours which is not at all tolerable. Is there a way to define a filter on users to be aggregated, for example only aggregate users with admin userlevel.
Hi @vishnujothi, thank you for sharing. As of now it is not supported. I am aware about this scenario and in this 2H '24, we are working on several enhancements that includes providing capability for aggregating users based on a user level like aggregate users with admin user level/permissions.
Currently weâre looking into using this connector. According to the initial post as well as the documentation Create Account is supported, but weâre wondering how this works and âwhereâ the account is created.
We aim to use this also âcross-tenantâ, so that an identity in production can request access in development, would that be possible?
What I donât understand is whatâs the point of doing a full aggregation of identities as accounts. For example, I want to filter the creation of accounts only for those who have user-level access, but from what I understand, itâs not currently possible. Whatâs the point of the profile of âcreate accountâ in the source if we are creating accounts for all identities?
I am trying to use this connector. I have configured, test in sandbox and tried to configure it in prod.
I am getting timeout error in test connection. I am not sure on how to troubleshoot saas connectors. Are there any logs available on customer side for saas connectors developed by Sailpoint team. I know there are logs available through sail if you are developing connectors. Can you share document links using which I can troubleshoot errors with saas connectors developed by sailpoint.
Hi @ragavi, yes, we are working on it to add more flexibilities where you can aggregate users based on a user level like aggregate users with admin user level etc. For other use cases as well, we are working on it and there will be releases updates once those are available. Thanks!
Hi @sauvee, âcross-tenantâ use cases are not supported. I would suggest to open an idea for this one.
For create account, âaccountâ will be created for this source only. If you are already scheduled an aggregation, you might not require this account creation capability. It is for the use cases, where customer just wants to do the aggregation once and still wants to manage access for user levels and governance groups. Thanks!
Hi Kathryn, not sure if this helps but we have some good provisioning related video chapters that cover various topics here:
It might help to browse through some of these. But if youâre needing more definitive assistance, you may want to provide additional details in terms of your use case, what app/system youâre connecting to, and the outcome youâre trying to achieve.