Thanks for posting to PX Community @Stuart !

1 PX User based on that unique IdentifyId.  

Gainsight PX leverages a unified User/Account model, so there is only one primary PX Account and PX User record that includes all associated default/custom PX User/Account attributes across all PX Products, Environments, and Channels within a PX Subscription.  These PX User/Account records are created and updated using their unique identifiers that you have passed to PX, which is their primary id/key.

You will notice that on the PX User Profile their Account is referenced as “Last associated Account id”, so many of our customer do exactly what you are trying to do and treat PX Accounts as tenants/instances/organizations that the same user can be associated to over time. 

If you let the user “bounce around” to different PX Accounts based on their latest PX Identify call content, all user usage stays with the user and account usage stays with the accounts.  Therefore, you can successfully analyze usage at an account level or user level.  However, the PX User will only be associated to the last associated PX Account if you are trying to filter by Account in PX Analytics.

I hope this helps!

Hey @link_black, thanks for the response!  To confirm, if we wanted to take the 1 user per tenant approach, the user id would need to be specific to the tenant?

If I understand correctly, say we used SFDC Contact Id as the identify id, account id would change based on last tenant they logged into.  For user-per-tenant, we would need a tenant-specific identify id and keep the SFDC Contact Id as a custom user attribute?

Yes, but doing that is not recommended at all as this will create multiple PX Users for the same actual user.  This leads to higher MAUs and no “single view” of a user analytics in PX and outside of PX too (e.g. Salesforce, Customer Success).  And, maybe even more importantly, the same Engagements/Surveys could be viewed multiple times by the same user as they have more than one PX User record, which is a bad experience.

In your scenario, I would recommend always using the SFDC Contact Id as the IdentifyId for each user, regardless of tenant/account association.

@Stuart I would also recommend passing the SFDC Account Id to your PX Account attributes, which can then be used to group the PX Accounts, which you are using a SFDC Account tenants, together in other systems such as Salesforce and GS Customer Success.

Thanks @link_black, appreciate the confirmation on how this works.

The decision on whether SFDC Contact/Account Ids are used for user.id and account.id in PX will be a Product Team decision, because ultimately that will decide whether accounts in PX are at the tenant level, or at the account level.

In terms of the CS org leveraging the data, we can set the lookup to the company and person objects depending on how we bring the data in via adoption explorer (although I’m not sure how this would impact custom events as a data source in HRE/DD); sure, a lookup to the data would cause multiple rows per Person/Company Id, but these can be aggregated.

For sure, you’ve armed us with the knowledge to have a broader discussion on a standardized approach to identifiers across our products with multi-tenancy enabled - really appreciate it!