Having been in the Salesforce ecosystem for almost 20 years – as a customer (sometimes, some features’ first), in product management, and in the CSG data strategy practice as a Salesforce employee, consultant, and ISV partner – I’ve had the privilege of witnessing many features and products evolve over the years from different perspectives and vantage points. There are three things that have always been consistent:
- Salesforce’s value proposition is delivering business value through its platform, as opposed to customers needing to figure out how to integrate multiple disparate technologies.
- Business value is centered around understanding the customer.
- There will be acquisitions, features, and guidance that will occur as Salesforce better understands friction points.
These friction points can be quite real. Some of you might have scoffed at the remark, “as opposed to customers needing to figure out…” since there are still different technology stacks, and Salesforce professionals are tasked with tackling the technology integration and configuration challenge every single day.
Still, I believe Salesforce presents the best enterprise business application platform in the ecosystem for the past two decades. The stories below are my experiences and recollections. The details may not be exact, especially around dates. But if you know of earlier or different stories, don’t hesitate to share!
How the Person Account Was Born
The year was around 2004 or 2005. At that time, I worked for Genentech as an Enterprise Architect, focusing on – you guessed it – data. Data modeling, data warehousing, data quality, data integration, master data management, and data migrations…
Genentech was the first biotech company in the world. We were working to launch new products, many to treat cancer. We’d meet real patients or providers, who motivated us to be at our best selves daily. Our CEO was a scientist, and in IT, we embraced similar principles: form a hypothesis and an effective way to reach a conclusive outcome and monitor if new technology can be safer, more effective, and more convenient to meet business outcomes.
Genentech was launching multiple new products or indications, and IT was focused on reducing friction as much as possible. We had multiple SFAs for different brands, we had just completed our ERP implementation, and we were not looking forward to the upgrade challenge. SaaS’ value proposition of no downtime or resource distractions for upgrades was compelling.
In 2005, the most common CRM solutions considered by life sciences companies included SAP, Siebel (which was acquired by Oracle), and Cegedim Dendrite. Of these, many had either just started entering the SaaS space or were still on-prem only. Salesforce was the leader in SaaS, with its value proposition centered on ‘No Software’, so we decided to evaluate them.
I remember noticing one key challenge from a data modeling perspective: Salesforce’s key objects were lead, account, contact, and opportunity. The assumption was that opportunities would be at the ‘company’ level, which wouldn’t work for us.
Salesforce SFA’s data model for opportunity tracking may not work for life-sciences-tracked leads, which then became opportunities on accounts that had business contacts. Key business applications focused on tracking leads and opportunities for account contacts. Biotechs, like other life sciences companies, ultimately engage with medical professionals.
When you sell software or hardware widgets to a company, you are dealing with business contacts at a company. What makes life sciences different is, first and foremost, you need to know who the healthcare professional is and where that person works, teaches, and interacts with patients. These places may include a hospital, clinical, private practice, etc. Doctors will prescribe drugs wherever they practice, based on the patient’s need, and relationships are tracked at the individual level.
We met and whiteboarded with professionals from Salesforce, and as I recall, Verticals on Demand (now Veeva). Our goal was to minimize customization that may lead to future upgrade challenges. The proposal was: “What if there was a single record that was linked across account and contact objects, so we could still maintain contact records but track opportunities for that individual within the account object?”
In 2005, Salesforce launched Person Account as a feature. Were we the first customer? Perhaps. What’s most important is the outcome – it worked for us. We set up person accounts for healthcare professionals, used accounts for healthcare organizations, and created and maintained relationships between the two, facilitated by master data management, human processes, and technologies.
Salesforce SFA to Salesforce CRM
As we migrated more and more SFA (Sales Force Automation) instances to Salesforce, we identified another common need. Our sales reps would be consistently asked about the status of their reimbursement requests, which was facilitated by another department using a homegrown case management solution.
In 2007, there was no Service Cloud. However, Salesforce’s security model was well-defined, with objects and rows, with field-level access had already been available for several years. We extended Salesforce SFA with custom objects that were tightly protected to keep confidential information secure while also providing a summary status on cases for account executives to facilitate their follow-up discussions with customers.
In 2009, Salesforce launched Service Cloud. I remember frequent meetings with Salesforce, who wanted to understand how we were pushing the platform to its limits. We wanted to focus on supporting our business users, not developing software, so the productization of custom features benefited both parties.
One of my common phrases is, “Whatever is repeatable is automatable.” Understanding human processes and identifying friction is a great place to drive business value. This was true then, and it remains true now – except now we have Flow and even Agentforce to further streamline how end users can be supported.
Interlude: Data.com and My Journey to Salesforce
In 2009, Roche Pharmaceuticals acquired Genentech, and we went through an application rationalization exercise. The goal was not only operational efficiency but also to maintain a consolidated application stack that enabled our end users to have a complete, contextual, and compliant understanding of their customer interactions. Our data-driven ‘analyze → configure → migrate → validate’ approach, which we had streamlined over the years, served us well during this time. We had the people, processes, and technologies for master data management, data profiling, cleansing, enrichment, integration (batch, messaging, federation), and warehousing to do this consistently.
In 2010, I was faced with an opportunity. Salesforce had just launched Data.com and was looking for a product manager with practical data management experience. I had been speaking at data management conferences and realized Genentech was a unicorn – most organizations did not have the funds, culture, people, processes, or technology to tackle data management challenges the way we had. The idea of productizing data management tasks was compelling, so I joined Salesforce as the company’s first head of data quality, and in a dual role, also served as a product management director in Data.com.
Salesforce CRM to Customer 360
Salesforce’s B2B Customer 360 journey started with Data.com, specifically by bringing in matching and enrichment capabilities, at the time powered by the Jigsaw acquisition and Dun and Bradstreet partnership into the platform. Instead of creating external (monthly batch) processes to see how accounts were related to a reference set, an admin could configure Data.com match and enrichment rules within minutes, view the candidates and additional information in a related object, and build business-centric solutions based on this.
Source: Dreamforce ‘15 Building a Customer Master Strategy in Salesforce
The number of capabilities to set up and configure may seem like a lot, but at that time, setting up a master data management architecture that delivered business value would typically take 9 to 18 months and cost between $1.5M and $5M, with a low business success rate.
Releasing features was not enough. One of the top factors impacting CRM adoption – and thus renewals – was poor data quality. In 2014, I was asked to create a data practice in CSG with the goal of bringing rapid assessment and improvement patterns to customers. The most common challenges included identifying and dealing with junk and duplicate data, creating an account hierarchy for a 360-degree understanding of customers, and how enrichment can provide more up-to-date information on business contacts.
Between 2013 and 2016, Salesforce also made some major acquisitions, specifically ExactTarget and Demandware, entering into the B2C space. Retail became a big opportunity, with a clearly defined challenge: how to understand the consumer when subscriber data is in ExactTarget, eCommerce customers and orders are in Demandware, and case records are in Salesforce CRM Service Cloud.
Journey to Salesforce Customer 360 and “Sam Smith”
Salesforce announced a broadened Customer 360 vision and the Data Manager product at Dreamforce ‘18. The decision to tackle “identity resolution” within the platform, as opposed to the traditional master data management technology approach, was significant – at least for the IT professionals often tasked with this challenge. This chapter continued through to the Dreamforce ‘22 launch of Data Cloud, which offered further improvements.
If you are working on Agentforce, Data Cloud, multi-org data unification, or legacy org to industry cloud migration today, there is much you can learn from the data-centric messaging from this chapter.
Each data source has its own data quality, based on the business processes it supports. For example:
- eCommerce solutions have guest check outs not linked to a customer.
- An eCommerce order can have three types of customer data: buyer, payer, and receiver.
- Service cases may be related to sparsely populated contacts without a Customer 360 starting point.
- Most subscriber records have only one contact point, and personalized engagement requires an understanding of interactions and consent at the individual, contact point type, and contact point level.
- To understand the customer, we need to think about what data is available when, its formatting, field value density for standardization or cleansing, and even how customers may be named. The person in the middle of many Customer 360 slides is named “Sam” because it is an androgynous name, and one needs to be mindful of when to match Sam to Samantha vs. Samuel.
While Customer 360 Data Manager provided customers with an in-platform way to tackle master data management challenges, the need to connect CRM orgs, Marketing Cloud, and eCommerce instances using different technologies remained too high a barrier. Organizations want a true single source of truth for marketing, sales, service, and engagements.
In 2021, Customer 360 Data Manager was retired, with core functionality brought into Customer 360 Audiences, which broadened its scope from marketing to enterprise use cases.
- The Data Cloud team leveraged connectors from MuleSoft and data transform capabilities from the analytics products to provide a single-platform approach to deliver data for any business use case.
- Data enrichment solutions (e.g. from Acxiom) and Data management solutions (e.g. Cuneiform for secure in-platform data analysis) continue to expand the platform’s capabilities, just as they did in 2005 when AppExchange was launched.
- Data Cloud is now the provider of the elastic compute infrastructure for Agentforce as well.
Customer 360 in Industry Clouds – NPSP to NPC Example
When the NPSP data model was first introduced, one of the most common use cases was the ability to report on household donations for overall relationship tracking and tax reporting purposes. NPSP organized individuals under a Household Account record type, with the ability to associate contacts with other accounts as well.
From a technical standpoint, this may look good. However, when we incorporate information lifecycle management – or how people’s relationships with each other change – and the need for better data management, relying on a single contact record is not always feasible.
Let’s imagine this scenario:
You have Sam, who donates to a non-profit using her personal email, but works for a company that manifests grants for the non-profit with a different email. The data tracking needs much more complication, but let’s start with this example. The people entering the data and interacting with these roles are distinct and different. We are likely using name and email fields on contact records where they may have the same phone number, but otherwise, the records may not be related at all.
Non-Profit Cloud embraced the importance of tracking the relationship with the individual via person accounts and the ability to associate the individual to any number of entities, with specific affiliation or relationship details. A person account can also relate to a single unified individual in Data Cloud, providing a more holistic understanding of relationships, not only within the single CRM org but across multiple data sources.
Why Does CRM Duplicate Management Work Differently Than Data Cloud Identity Resolution?
As Salesforce professionals, we need to understand what a particular feature can do, and ideally, why it was created, in order to understand its potential and limitations.
A question I often get is: “Why do we need to do identity resolution in Data Cloud? Can’t we just use duplicate management in Salesforce?”
Salesforce’s duplicate management feature was created to catch and prevent unintentional duplicates, as well as to facilitate data cleanup by merging records while bringing related transactional content together.
As you can see in the non-profit example, sometimes we need intentional duplicates or distinct records about the same person or same organization, while having a holistic understanding of the entity. This is what Data Cloud’s matching approach enables. There are algorithmic differences as well.
- In Data Cloud, “415-555-1000” and “(415) 555-1000” would be an exact match, but “415-555-1001” would not be.
- In Salesforce CRM duplicate management, “415-555-1000” and “415-555-1234” would be considered an exact match.
When duplicate management was first introduced in 2015, the goal was to catch and prevent bad data entry, often by end users. The algorithms took a ‘broad’ vs. narrow approach. Your key takeaway for this section – no matter what technology you use – is to understand how match rules work to ensure you don’t have false positives.
Summary
Salesforce has been on a decades-long quest centered around trust and customer success by providing features that enable faster business user adoption of technology capabilities. Some ideas that were great a decade ago may still be relevant today, while others may have been replaced by newer solutions.
Understand what is needed by applying business analytics best practices. As an architect or admin, know what is possible, and remember to keep learning and sharing as you make choices along the way.
If you have other stories or perspectives, please reach out and share.
