
The reference library of the Acellas data practice
Drawn from two decades of Salesforce data work and arranged by the reader's starting point; each page stands on its own.

Reference data, identity and data quality
What Salesforce reference data is, and why an agent depends upon it
The records an agent reads, how they relate, and the four properties each must hold.
Record identity: Salesforce IDs, legacy IDs and external IDs
Salesforce IDs in 15 and 18 characters, external IDs, and the role of legacy IDs.
How Salesforce duplicate records arise, and what merging them changes
How duplicates bypass the duplicate rules, and why the merge is the consequential part.
The Salesforce account hierarchy: end users, bill-to, ship-to and subsidiaries
Parent accounts, bill-to, ship-to and customer–subsidiary relationships, and what the Account must carry for the ERP.
Retention criteria: deciding what to keep
Deciding which records to keep, object by object, and why that comes before the data scope is set.
Why data degrades, and why cleanup without correction at the point of entry regresses
Why data degrades, why a single cleanup regresses, and the controls that hold.
What determines the complexity of a data engagement
Why what the data must represent, not volume, usually sets the difficulty of the work.
Glossary of terms used in Salesforce data work
The Salesforce data terms that the library assumes.
How a remediation or migration is run
The Salesforce data assessment question set, by object
Sample questions our consultants ask of each object before any scope is written.
Object, field and value mapping
What mapping records at the object, field and value level, and why the client signs off the decisions.
Validation: scope, mapping, pricing and the reports that prove them
What every load is checked for, and the reports that prove it.
Test cycles, wipe and reload, and cutover
Why each test cycle starts by clearing and reloading the migrated records, and how the cycles are sequenced.
The exceptions catalog: contract-line anomalies and the questions they raise
Contract-line anomalies often found in legacy data, the question each raises, and the risk if it is left unexamined.
What the client contributes to a data project
What a client typically brings to a data project: access to its systems, decisions only it can make, and the people who know the data.
The data migration environment
The temporary database between the sources and Salesforce, and why it stands apart from both.
Privacy, security and access: the constraints that shape the work
Where migration data may be processed, by whom, and under which controls.
Consolidating multiple Salesforce instances
Merging Salesforce orgs, where the hard questions concern precedence, not transfer.
Salesforce CPQ contracts, pricing and ARR
The Salesforce CPQ price waterfall and the prorate multiplier
How Salesforce CPQ derives each price, and the prorate multiplier.
Salesforce CPQ bundles: parent, child, option and root
The fields that express a bundle hierarchy, and how a missing bundle header is built.
ARR, TCV and ACV: definitions and reconciliation
How ARR, TCV and ACV are defined, and why each must be calculated the same way in the source and the target.
Cutover, the ERP, files and SQL
The production cutover runbook
What happens before, during and after the production load, and how each load is confirmed.
Salesforce and the ERP: what must agree for billing and revenue recognition
How Salesforce contract data corresponds to the ERP's billing records, and what each side requires.
Files, rich-text images and knowledge articles
Moving attachments, inline images and knowledge articles between Salesforce orgs.
Working patterns in the migration database
Preliminary profiling, identifier conversion, fuzzy matching and validation in the migration database.
Questions about the Salesforce data guide
What is Data U?
Data U is the Salesforce data guide from Acellas, drawn from two decades of Salesforce data work on client projects. It covers reference data, identity, duplicates, migration, validation, cutover and Salesforce CPQ data, which also matters to teams moving from Salesforce CPQ to Revenue Cloud, and each article stands on its own, so a reader can begin with the question at hand.
Where should a reader start?
With the collection that matches the reader's starting point. Data 101 suits readers who need the vocabulary and the mechanisms by which data degrades, Data 201 those who plan a remediation or a migration, and Data 301 those who work with Salesforce CPQ, are moving from it to Revenue Cloud, or carry out a migration. For a hands-on start, Salesforce offers a Trailhead data quality module.
Who writes the Salesforce data guide?
Acellas data experts write the guide and perform the work it describes. Our senior experts specialize in data and bring two decades of Salesforce data work, and every article draws on what our experts have learned on client projects.
Using the Salesforce data guide alongside Acellas services
Does the guide help with Agentforce?
Yes. Agents read the reference data the guide describes: accounts, contacts, products, contracts and prices. Data 101 explains the four properties each record needs, and Data 201 sets out sample assessment questions by object. The service itself is described under Agentforce data readiness.
Is the guide only for teams on Salesforce CPQ or Revenue Cloud?
No. Data 101 and Data 201 apply to any Salesforce org, whatever the products in use. Data 301 covers the Salesforce CPQ detail that determines whether contracts amend, renew and bill correctly, from the price waterfall and bundles to ARR, TCV and ACV. It also covers the production cutover and the migration database, which apply to any migration.
How does the guide relate to Acellas services?
Each collection covers the topics behind a service. Data 101 and Data 201 support Agentforce data readiness work, and Data 201 and Data 301 a Salesforce data migration, so a reader can understand the issues before speaking with the experts who handle them.
Assess the data before the agents depend upon it
A conversation with the practitioners who wrote the guide.