Salesforce Certified Data Architecture and Management Designer (SU18)
Difficulty: Intermediate | Prerequisites: Familiarity with Salesforce standard objects (Account, Contact, Lead), basic understanding of relational data models.
The Data Architecture exam tests your ability to choose the right relationship type (master-detail, lookup, or indirect lookup) for a given scenario, model B2C consumer data using Salesforce's Account-Contact paradigm, select appropriate platform licences, and identify the key artifacts for documenting a multi-system data architecture. The scenarios are practical: a set of business requirements, and you pick the design that satisfies them.
Master-detail relationship
A tightly coupled parent-child relationship in Salesforce where the child (detail) record cannot exist without the parent (master). Deleting the master cascades to the child. The child inherits the parent's sharing and security settings. Roll-up summary fields are available on the master.
In simple terms, the child record's life depends on the parent. Delete the parent, and the children go with it.
Lookup relationship
A loosely coupled relationship where the child record can exist independently of the parent. Deleting the parent does not automatically delete the child. The child has its own sharing and security settings.
In simple terms, a lookup is a reference, not a dependency. The child can stand on its own.
Indirect lookup relationship
A relationship that links a child object to a parent object using a custom unique external ID field on the parent, rather than the standard Salesforce record ID. Used primarily when integrating with external data sources.
In simple terms, it lets you join records by a key from an outside system instead of Salesforce's own ID.
External ID
A custom field on a Salesforce object marked as an external ID, meaning it holds a unique identifier from an outside system. External IDs are indexed, can be used for upsert operations, and support indirect lookups.
In simple terms, it is how Salesforce knows that record X in your org is the same entity as record X in your ERP or MDM system.
B2C data model (Business-to-Consumer)
A Salesforce data modelling pattern for organisations that deal with individual consumers rather than business accounts. The recommended approach is to create one Account record and one Contact record per individual consumer.
Lightning Platform Plus licence
A Salesforce licence type designed for custom application development. It supports a higher number of custom objects (up to 110) and a higher API call limit compared to Lightning Platform Starter, making it suitable for organisations building substantial custom apps.
Data model (architecture artifact)
A visual and structural representation of the objects, fields, and relationships in a Salesforce implementation. One of the two key artifacts (alongside the integration specification) for documenting a multi-system enterprise data architecture.
Integration specification
A document describing how data flows between Salesforce and external systems: what data moves, in which direction, how often, through which API or middleware, and what transformations apply. The second key artifact for documenting enterprise data architecture.
Choosing the correct relationship type is one of the most frequently tested areas on this exam. The decision turns on a few key requirements.
When to use master-detail
The child record should not exist without the parent.
Deleting the parent should cascade-delete the children.
The child should inherit the parent's sharing and security rules.
You need roll-up summary fields on the parent.
The master-detail field is always created on the child (detail) object, pointing to the parent (master) object.
Exam scenario
A company is migrating legacy inventory data into a custom Inventory__c object related to the standard Account. Requirements: the child inherits Account sharing rules, and deleting an Account deletes related inventory records. The correct answer is a master-detail relationship field on Inventory__c, related to Account.
A common distractor places the master-detail field on Account. Remember: the field lives on the child object.
When to use lookup
The child record should be able to exist independently.
You do not need cascade delete.
You do not need the child to inherit the parent's sharing model.
Exam scenario: converting master-detail to lookup
A company has a discount request object as a detail of a product object. They need to allow discount requests without a parent product. The recommended solution is to change the master-detail relationship to a lookup relationship. This makes the parent optional.
Creating a placeholder parent record is a workaround, not a best practice. Removing the relationship entirely loses the association. Mandating a product defeats the requirement.
When to use indirect lookup
You are integrating with external data sources (e.g. Salesforce Connect / OData).
The parent record is identified by an external ID rather than a Salesforce record ID.
Salesforce's standard data model centres on the Account-Contact pair. For B2C organisations (those selling to individual consumers rather than businesses), this creates a design question: where do individual consumers live?
Recommended approach
Create one Account record and one Contact record for each individual consumer. This is a one-to-one pairing.
Why this works
It preserves Salesforce's standard functionality on both objects (e.g. Activities on Contacts, Opportunities on Accounts).
It avoids data-loading issues that arise from stuffing all consumers under a single shared Account or skipping the Contact object entirely.
Person Accounts (which merge Account and Contact into one record) are another option, but the exam scenario here points to the explicit one-Account-one-Contact pattern.
Alternatives and why they are wrong
Creating a custom object for consumers bypasses all the standard CRM functionality built around Account and Contact.
Loading consumers only as Accounts (skipping Contact) loses Activity tracking, email integration, and other Contact-dependent features.
Loading all consumers as Contacts under a single Account creates a data quality and ownership nightmare, and the single Account becomes a bottleneck for sharing rules, ownership, and triggers.
When an organisation builds a custom application on Salesforce (rather than using Sales Cloud or Service Cloud), the licence type matters.
Exam scenario
A company wants to build an HR application requiring 45 custom objects and roughly 20,000 daily API calls from an on-premises system. The correct licence is Lightning Platform Plus.
Why Lightning Platform Plus
It supports up to 110 custom objects (well above the 45 needed).
It includes a higher daily API call allocation than Lightning Platform Starter.
It is specifically designed for organisations building custom apps on the Salesforce platform, as opposed to using pre-built Sales or Service Cloud functionality.
Distractors
Service Cloud is a CRM licence, not a platform licence. It would bring unnecessary Sales/Service features and may not support the custom object count.
Lightning Platform Starter supports only 10 custom objects, which is far too few.
Lightning External Apps Starter is designed for portal/community users with limited internal access, not for a full internal HR application.
A master-detail relationship enforces that the child record must always have a parent. When a business requirement emerges for child records to exist without a parent, you need to change the relationship type.
Pattern
Change the master-detail relationship to a lookup relationship. This makes the parent field optional on the child record.
Why not other approaches
Creating a placeholder parent record is a data quality hack, not a design solution. It introduces a fake record that can confuse reporting and downstream integrations.
Removing the relationship entirely loses the link between the objects, which defeats the purpose of having related data.
Mandating a parent selection contradicts the requirement of allowing child records without a parent.
For a multi-system, enterprise Salesforce implementation, the exam expects you to know which artifacts matter most.
The two key artifacts
Data model - describes the objects, fields, relationships, and data types across all systems. This is the structural blueprint.
Integration specification - describes how data flows between Salesforce and other systems: direction, frequency, API method, error handling, and transformation rules.
Why the others are not the answer
User stories describe what users need to do, not the shape of the data.
Non-functional requirements cover performance, availability, and security constraints, which are important but are not the primary artifacts for documenting data architecture specifically.
Students often place the master-detail field on the wrong object. The field always lives on the child (detail) object, not the parent (master).
Students sometimes think a lookup relationship provides cascade delete. It does not. Cascade delete is a master-detail behaviour.
Students confuse "Lightning Platform Starter" with "Lightning Platform Plus." Starter supports only 10 custom objects, which is insufficient for large custom apps.
Students sometimes assume that user stories or non-functional requirements are the primary data architecture artifacts. They are not. The data model and integration specification are the two the exam expects you to name.
Relationship type questions appear frequently. Read the requirements carefully for cascade delete, sharing inheritance, and whether the child must have a parent. Those three clues determine the answer.
The B2C data model question tests whether you understand the Account-Contact paradigm. One Account + one Contact per consumer is the standard recommendation.
Know the licence types and their custom object limits. Lightning Platform Plus (110 custom objects, higher API limits) is the answer when the scenario describes a large custom app.
The data architecture artifacts question is straightforward: data model + integration specification.
True or false: A master-detail relationship field is created on the parent (master) object. (False. It is created on the child/detail object.)
Fill in the blank: To allow a child record to exist without a parent, change the master-detail relationship to a ______ relationship. (Lookup.)
True or false: For a B2C migration, the recommended approach is to load all consumers as Contacts under one shared Account. (False. Create one Account and one Contact per consumer.)
Fill in the blank: Lightning Platform Plus supports up to ______ custom objects. (110.)
True or false: User stories are one of the two key artifacts for documenting enterprise data architecture. (False. The two are the data model and the integration specification.)
Q: A custom child object needs to inherit the parent Account's sharing rules and be cascade-deleted when the Account is deleted. What relationship type should be used, and where is the field created?
A: A master-detail relationship field on the child object, related to Account.
Q: A detail object currently requires a master record but the business now needs records without a parent. What should the architect recommend?
A: Change the master-detail relationship to a lookup relationship.
Q: A B2C company is migrating one million consumer records to Salesforce. What is the recommended data model?
A: Create one Account record and one Contact record for each individual consumer.
Q: A company needs 45 custom objects and 20,000 daily API calls for a custom HR app on Salesforce. Which licence type fits?
A: Lightning Platform Plus.
Q: Which two key artifacts should an architect use to document a multi-system enterprise Salesforce data architecture?
A: A data model and an integration specification.
Relationship types connect directly to the data migration topic (covered in the third set of study notes), where maintaining master-detail hierarchies during org-to-org migration requires careful sequencing and external ID mapping. The B2C data model topic links to Person Accounts, which are covered in the Salesforce Identity and Access Management Designer exam. Licensing connects to org governance and multi-org strategy.
Master-detail relationship, lookup relationship, indirect lookup, external ID, cascade delete, sharing inheritance, roll-up summary field, B2C data model, Account-Contact, Person Account, Lightning Platform Plus, Lightning Platform Starter, custom objects limit, API call limit, data model, integration specification, data architecture artifacts, enterprise architecture