@erickinfoblox redirecting this to product. 

Just in time provisioning would be a great enhancement for the SSO connector.  For example, we use this feature with Zendesk and accounts are provisioned when the users login for the first time.  It saves administrators from having to create the accounts each time, as well as deactivating them.  OneLogin is our SSO provider.

@seth  - there is a similar topic/idea published here.  Can these be combined as JIT/SCIM is widely used by many of the common iDP’s (Okta, AAD, Google, etc)?   

Thanks for pointing the duplicate Idea @rterakedis, merged that one into this (as this egg came earlier)

@anirbandutta - is there any update on this?  Our internal Security team is making a big push for internal tooling to adopt automated user/role provisioning.   I would like to add that SCIM is only *half* the equation of getting users access.   Once the user is added to PX, there also needs to be a method of controlling what Role/Permissions they get.   We don’t want new users given a default role of full admin.

If the role is not added from Okta, perhaps the default role can be Viewer.

@anirbandutta - any update on this?   

Also, there’s another similar idea gaining votes that you may want to merge here:   

@rterakedis @mmarques  We are looking to consider SCIM Apis for CS first, and in general could be extended for other products. Want to understand more about your onboarding processes and usecases, will your team be open for a discussion?

@Kartheek - Possibly. If you send me an email, then I can get the right people involved in the discussion. You can get my email from @MBragle or @aharkut.

@Kartheek - Happy to broker a discussion with our security team.  Our CSM is @jmobley - he can get you my email address and start a thread.  Thank you for reaching out!   

thks @mmarques , @rterakedis I will follow up though email

@Kartheek - adding here for everyone’s benefit and to allow commentary from the community:

Some requirements as we would define them:

• SCIM configuration separate between sandbox and production Gainsight CS/PX environments.   We would want any SCIM/permissions testing isolated to sandbox environments using sandbox identities.  no mixing sandbox & production.
• SCIM syncing users (particularly from a certain group) into CS/PX -- we wouldn’t want to bulk sync everyone in our company into Gainsight.
• SCIM syncing groups (either our IAM system creating the group, or prestaging the group in Gainsight tools and then just syncing membership)
• Roles/permissions/entitlements assigned to the groups within Gainsight, not directly to the users.   Membership in the group grants the appropriate roles/permissions/entitlements.
• Rest API to allow User/Group management:
  • This allows our IAM system to audit permissions in the Gainsight tools match what is assigned via IAM.
  • Allows us to discover if a Gainsight admin has changed permissions/entitlements for a user outside of the IAM system.

From a “Process” perspective, we map users to “roles” (such as a CSM versus a Product Manager) so that new employees can inherit permissions similar to their coworkers.  We also use the IAM system for an approval workflow if an employee requests an app permission or role that is not added by their base job role (like if a PM needed access to CS in order to see account history).

Is there any sort of ETA when SCIM/JIT will be supported in Gainsight CS or any other of your products like PX? It seems odd that its not supported yet. I would pretty much like to do what rterakedis-9222 stated in a previous reply 9 months ago. 

My company's requirements are the following for SCIM/JIT:

• SCIM configuration separate between sandbox and production Gainsight CS/PX environments.   We would want any SCIM/permissions testing isolated to sandbox environments using sandbox identities. no mixing sandbox & production.
• SCIM syncing Users and Groups (We would want to use Groups in order to control who syncs) into CS/PX. We don't want to bulk sync everyone in our company into Gainsight.
• SCIM syncing groups (either our IAM (Sailpoint IDN or Entra ID system creating the group, or prestaging the group in Gainsight tools and then just syncing membership)
• Roles/permissions/entitlements assigned to the groups within Gainsight, not directly to the users.   Membership in the group grants the appropriate roles/permissions/entitlements.
• Rest API using Sailpoint IDN to allow User/Group management:
  • This allows our IAM system to audit permissions in the Gainsight tools match what is assigned via IAM.
  • Allows us to discover if a Gainsight admin has changed permissions/entitlements for a user outside of the IAM system.

From a “Process” perspective, we would like to map users to “roles” (such as a CSM versus a Product Manager) so that new employees can inherit permissions similar to their coworkers.  We also want to use our IAM system for an approval workflow if an employee requests an app permission or role that is not added by their base job role (like if a PM needed access to CS in order to see account history).

Thanks ​@giopineda for your comments. On SCIM for CS, we are currently working on it and the initial version of it will be available in next quarter. 

​@Kartheek this is great news! Will it be GA as soon as it’s available? Is there a more concrete timeline yet? We need this ASAP!

Thanks for reaching out ​@jenlpro. We plan to go GA tentatively by Q2 release. Will share details in an email soon