Allow SFDC Contacts to be the source of truth in Gainsight instead of Company Person/Person

I think the Person architecture is over-engineered and, a pain to work with. Data loads through rules instead of a 1:1 connection, the connectors themselves are difficult, and the result is a steady stream of duplicates that are hard to manage at any scale.

I'd love the option to rely solely on SFDC Contact instead. The human-first intent behind Person made sense on paper — give Gainsight contacts a real identity beyond just a CRM record — but in practice it's created ongoing admin overhead and an inevitable delta between Gainsight and Salesforce that end users can never wrap their heads around.

Short of that, the compromise is a genuinely solid connector that keeps Person in sync with SFDC natively, without me having to babysit it. Every company I've worked at has eventually needed a dedicated cleanup project for Gainsight Person data. That's time I'd rather spend on work that actually moves the needle for CS.

I could not agree with this more and wish I had  x  votes to give this.

Ever since Gainsight NXT arrived and GS shifted away from allowing Salesforce Contacts to be used for things like external attendees, etc. contact management has been a blight on productivity, introducing unnecessary administrative overhead and confusion for both admins and end users. 

As ​@spencer_engel noted, Gainsight needed a contact management function that wasn’t tied to Salesforce so they could expand their footprint beyond Salesforce. I get it. But for those of us who remain dependent on Salesforce, and upstream data management processes and hygiene (or lack thereof) out of our direct control, the People model is an absolute nightmare trying to keep in sync between platforms and trying to explain to users why there are two different, but same entities, that must be kept in sync.

​@spencer_engel covered well the list of common issues we run into.

As a supporting example, I discovered recently that our community management team has been changing the email address and account assignments on existing Contacts (rather than creating a new Contact on the target account and flagging the old Contact as no longer active) which created this issue where the Person record gets it’s email address changed (because SFDC Contact ID and Email are my sync keys) resulting in a new Company Person getting created on the “new” account, and the email address getting updated on the Company Person mapped to the “old” account.  So the “old” CP is still active but with the individuals “new” company domain email address.  And these issues aren’t surfaced in Data Steward.

We also intentionally disabled the ability for users to create Persons/Company Persons in Gainsight because trying to keep them reciprocally synced was proving to be a big challenge, so now we surface Person and Contact reports on C360 instead of the Person widget.

IMHO this is the single most frustrating source of administrative (and end user) headaches, complications and challenges in Gainsight.

Literally still having issues related to this as we speak. Contact management (SFDC), person management and company people (GS), multiple systems, multiple places we’re assuming “source of truth” data or actions that pertain to post-sale people management, multiple systems that have to push and pull data to be “up to date” and like Spencer outlined, to still end up with an overengineered set of rules, complex series of multi-threaded rule chains, and we perpetually have orphaned records, duplicates, or “duplicates” that look like the same person but aren’t b/c GS handles person management in silos and so a person whose title changed or company association was updated ends up corrupted or changed just to have even more complex orphaned records with no way to resolve. This has been a headache at 3 orgs for me now and still we end up with a only half functioning “sync” that results in pained down stream areas.

….the system doesn’t work as designed. Simple as that. There needs to be a better solution and for SFDC connected orgs, this certainly would seem to do it

One of the more common mantras of an Ops org is to minimize friction and have clear processes and procedures. For something as critical as a contact database, which touches every facet of a business (Sales, Marketing, Product, Legal, Customer Success, Support, etc.), that is paramount. However Gainsight’s decision to not use the Salesforce (or any general CRMs) contact object means we’re essentially duplicating this across tools and leading to compounding confusion around:

• How & where to update contacts -- while Gainsight has the real-time sync, it is not feasible given the API call usage for our Salesforce teams.
• How often do those updates sync over?
• Silent per-contact failures if required fields are not populated
• Significant manual effort on the part of Gainsight admins to stay 1:1 with field deprecation or additions in the CRM.

Plus all of the above items that have already been mentioned. It’s a nightmare to implement & maintain and is a huge drain on resources.This alone would be one of the greatest QoL changes you could implement for those of us at Salesforce-dependent organizations.

FYI ​@rakesh ​@pgeorge - I know this doesn’t have many votes (yet - the day is still young), however it’s one of the biggest (if not the biggest) - and arguably one of the most broadly impacting - pains for both admins and users so want to make sure it’s on your radar.

Contact management continues to be the bane of our existence for the reasons above and more. However I can’t agree enough with what’s already been presented. Allowing the ability to toggle for a single source of truth for an already confusing and prickly problem would lessen its impacts where possible. 

This is such a pain, Company Person records cannot be merged or otherwise managed by outside system.  We have the same problems and have seen it pop up in different ways for the different Gainsight instances I’ve worked with.  When Salesforce is deployed with related contacted, which exactly mirrors the Company Person object, Gainsight simply can’t maintain when contacts are merged or deleted, and it makes auto-capture an absolute nightmare when contacts aren’t on the correct Company.

Yes, the Email Autolog feature was actually the impetus for me finally posting this idea. It’s a great tool for the 90% (?) of contacts that are correctly parented but an absolute nightmare for the ~10% that are messed up for one reason or another. And for us, the bad is starting to outweigh the good, which might force us to go back to just using the manual Gainsight Assist plugin.

The fact that so many well-known Gamechanger community legends have not only written the post itself or provided numerous examples within 24 hours of this idea’s creation should be highly indicative of the impact this issue has on the admin community. ​This is huge. We have to bring in our Salesforce contact records for nearly every program and merge them with company data, which seems highly unnecessary.

Just let us use Salesforce contacts and be done with it, please! 🙏

This would also simplify opt outs for email campaigns, as you would no longer have to consider two system and record sources for where someone might have opted out from, have aligned categories...the list goes on.

Staircase customers could also benefit from this too: There’s a feature where new contacts Staircase identifies can be added to your CRM with a click. Great, unless Gainsight is your CRM (which it might be, as that would give admins the most flexibility) and SFDC is your contact source of truth. If you could just leverage contacts, suddenly adding that contact from Staircase becomes less of a hassle.

There might be a third option, but it would require some serious improvements to the current model. Duplicates, merges, orphaned records right now are a manual and obnoxious pain to deal with in the best of times.

And for a platform that often rides heavily on the success of Journey Orchestrator, you’d think making contact accuracy and management would be a high priority.