Skip to main content
Solved

PX Identify Call - looking to create a user (aptrinsic id) per product tenant even if user id is constant

Stuart
Forum|alt.badge.img+3
  • Stuart
  • Helper ⭐️⭐️
  • 144 replies

Hey folks, identify id based question:

  • One product tag
  • user X can access multiple tenants on the same account.

Ideal scenario: looking for a user (aptrinsic id) per tenant, even if their user id is the same.

 

If we set user.identify id as a user identifier that stays constant across tenants, and account.id as the tenant the user is currently accessing, will this create 1 or 2 users (aptrinsic ids) in PX?

 

If not, we would need to look at setting the user.identify id as tenant-specific, and passing the constant user identifier (SFDC Contact Id) into a custom user attribute.

Best answer by link_black

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!

View original
Did you find this topic helpful?

5 replies

link_black
Forum|alt.badge.img+2
  • link_black
  • Gainsight Employee ⭐️⭐️
  • 316 replies
  • Answer
  • June 13, 2024

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!

-- Link
Stuart
1 person likes this
  • Stuart
    Stuart
Stuart
Forum|alt.badge.img+3
  • Stuart
  • Author
  • Helper ⭐️⭐️
  • 144 replies
  • June 13, 2024

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?

link_black
Forum|alt.badge.img+2
  • link_black
  • Gainsight Employee ⭐️⭐️
  • 316 replies
  • June 13, 2024

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.

 

 

-- Link
Stuart
1 person likes this
  • Stuart
    Stuart
link_black
Forum|alt.badge.img+2
  • link_black
  • Gainsight Employee ⭐️⭐️
  • 316 replies
  • June 14, 2024

@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.

-- Link
Stuart
1 person likes this
  • Stuart
    Stuart
Stuart
Forum|alt.badge.img+3
  • Stuart
  • Author
  • Helper ⭐️⭐️
  • 144 replies
  • June 14, 2024

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!

link_black
1 person likes this
  • link_black
    link_black

Reply


Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings