Data-Architect
Salesforce Certified Data Architect
Salesforce Certified Data Architect (SP24) Exam Guide
Salesforce’s current official name for this credential is Salesforce Certified Platform Data Architect; the supplied official sources do not explicitly identify a separate “SP24” version. The certification validates the ability to design sound, scalable, high-performing Salesforce Platform solutions for enterprise data management. It is aimed at architects and experienced Salesforce professionals who assess requirements, data quality, governance, migration, and performance. This guide helps you decide whether your experience is ready, which capabilities need deliberate practice, how to sequence your study, and how to choose an exam delivery option.
What the certification validates
The Platform Data Architect credential tests architecture judgment rather than isolated configuration recall. A successful candidate must translate business and information requirements into a Salesforce solution that remains usable, governed, performant, and maintainable as data volume and organizational complexity increase.
The official description places the credential around enterprise data management on the Salesforce Platform. That means an architect should be able to reason across the full data lifecycle: sourcing data, moving or integrating it, persisting it, managing metadata, reconciling meaning, protecting it, governing its use, and delivering useful outcomes.
The exam is intended for architects who assess an architecture environment and its requirements before designing a scalable and performant Customer 360 Platform solution. In practice, that requires balancing competing constraints instead of selecting a product feature in isolation.
The practical standard to use while studying
For every topic, ask four questions: What requirement is being solved? Where should the data live? What trade-off does the design introduce? How will the organization operate and govern it after implementation? This approach is more useful than memorizing definitions without connecting them to an architectural decision.
A strong answer usually accounts for data quality, relationships, access, ownership, integration boundaries, volume, performance, migration risk, and stewardship. If your proposed design solves only the immediate configuration request, it is probably incomplete for an architect-level scenario.
Who should take it
The credential is most suitable for professionals who already work with Salesforce data architecture and enterprise delivery decisions. Salesforce’s target background includes 2–3 years of Salesforce experience and more than 5 years supporting or implementing data-centric solutions, so candidates should treat this as an experience-based architecture exam rather than an entry-level Salesforce test.
Roles that align with the exam
The official exam guide lists Advanced Administrator, Data Architect, Technical/Solution Architect, and Advanced Platform Developer among the typical roles. The common thread is responsibility for designing or evaluating how data is modeled, moved, secured, governed, and used across a Salesforce environment.
An administrator may be ready when their work has expanded beyond individual objects and automation into enterprise data decisions. A developer should be ready to explain the architecture consequences of implementation choices, not only how to write code. A solution architect should be prepared to connect business requirements to platform limits, operational ownership, and long-term data quality.
A readiness test before booking
You are closer to exam readiness if you can defend a data model, explain why a relationship type fits a requirement, identify risks in a migration plan, and recommend a stewardship operating model. You should also be comfortable discussing indexing, large-data-volume performance, and the difference between an attractive design and a supportable one.
If your experience is mainly page layouts, routine administration, or isolated Apex tasks, begin with the underlying data architecture material before scheduling. The official target profile is a useful warning against treating the exam as a short feature survey.
Which capabilities are measured
The official exam guide groups relevant experience around data modeling and database design, master data management, Salesforce data management, data governance, large-data-volume considerations, and data migration. Use those areas as a capability map, then study the connections between them because architecture scenarios rarely isolate one concern.
Data modeling and database design
Expect to reason about custom fields, master-detail relationships, lookup relationships, requirements-to-database mapping, Salesforce standard objects, and big objects. Preparation should focus on choosing an appropriate structure for ownership, reporting, sharing, lifecycle, and scale—not simply identifying what each feature is called.
Practice converting a written requirement into entities, attributes, relationships, and ownership rules. Then challenge the first design: what happens when a record is deleted, when ownership changes, when a child needs an independent lifecycle, or when reporting must cross the relationship? Those questions expose whether the model reflects the business or merely the current screen flow.
Master data management and information architecture
The exam guide describes information-architecture building blocks that include data sourcing, integration or movement, persistence, master data management, metadata management, semantic reconciliation, governance, security, and delivery. Study these as a chain. A master-data decision affects integration, matching, stewardship, reporting, and the location of authoritative values.
Semantic reconciliation deserves special attention. Different systems may use different names, identifiers, definitions, or levels of detail for what appears to be the same business entity. An architect must establish how those meanings align before proposing synchronization or migration.
Salesforce data management
The scope includes the way Salesforce standard and big objects fit into a broader data design. Compare the purpose and operational implications of storing data in a conventional Salesforce object with the needs of very large, access-pattern-driven data. The decision should follow retention, query, ownership, reporting, and performance requirements.
Do not study objects as disconnected catalog entries. Start with a requirement and determine whether the platform representation supports the required relationships, access, lifecycle, and usage pattern. That reasoning is more transferable to scenario questions than a list of object capabilities.
Data governance and stewardship
Salesforce expects candidates to assess data-quality requirements, design solutions that support high-quality data, and recommend organizational changes for data stewardship. Governance therefore includes people, policies, accountability, controls, and measurement—not just validation rules or duplicate-management features.
Prepare to identify who owns a definition, who corrects a record, who approves exceptions, and how quality is monitored over time. A technically valid design can still fail if no team is accountable for duplicate resolution, reference-data maintenance, consent handling, or policy enforcement.
Large data volumes and performance
Large-data-volume topics in the official guide include indexing, large-data-volume migrations, and performance. The official architect Trailmix also points to data-performance topics such as the Query Plan Tool and query optimization. Study performance as a consequence of data shape, filters, selectivity, access patterns, automation, and migration sequencing.
When reviewing a design, identify the anticipated high-volume objects and the queries or processes that matter most. Then ask which filters are selective, which operations run repeatedly, and whether the proposed integration or migration pattern creates avoidable contention. Avoid assuming that a design is scalable because it works with a small data set.
Data migration
Migration requires more than loading records successfully. Prepare to reason about extraction, transformation, cleansing, matching, key preservation, relationship reconstruction, sequencing, validation, reconciliation, rollback or recovery planning, and post-load stewardship. Migration choices should support the target model and the operating model that follows it.
A useful exercise is to write a migration decision record. State the source of truth, identify transformations, define how parent and child records are associated, list quality exceptions, and specify how the business will verify completeness. This reveals gaps earlier than practicing load mechanics alone.
How to use the official study paths
Start with Salesforce’s recommended Architect Journey: Data Architecture and Management Trailmix, then use the exam guide to check that your work covers the full capability set. The Trailmix includes Data Modeling, Data Management, Large Data Volumes, Data Quality, Data Governance and Stewardship, Apex Basics and Database, and performance material such as the Query Plan Tool and query optimization.
A focused learning sequence
Begin with data modeling and requirements-to-database mapping. Next study data quality, master data management, and governance so that your model includes ownership and controls. Then move to migration and large-data-volume design, finishing with performance and implementation trade-offs. This order moves from structure to operation and finally to scale.
Use the preparation Trailmix as a second reference for exam-oriented study, but do not let a checklist replace scenario analysis. After each learning unit, create a short design problem and explain your choice in writing. The explanation should mention the requirement, the selected pattern, the rejected alternative, and the principal risk.
Build a personal architecture notebook
Organize notes by decisions rather than by product screens. Useful headings include relationship selection, authoritative source, identity and matching, quality control, stewardship, migration order, volume risk, query behavior, and governance escalation.
For each entry, record the condition under which a pattern is appropriate and the condition under which it becomes risky. This prevents a common failure mode: remembering a recommendation without remembering the boundary that makes it valid.
A practical study roadmap
Use a staged roadmap that converts experience into exam-ready reasoning. The exact calendar should depend on your workload and baseline, but each stage should end with evidence that you can apply the topic to a new scenario rather than merely recognize terminology.
Stage one: establish the baseline
Read the current official credential and exam-guide material first, paying attention to the naming distinction between Platform Data Architect and the requested SP24 label. List the domains you have handled in production and mark each as strong, familiar, or untested. Do not schedule from confidence alone; schedule from demonstrated coverage.
Next, choose a realistic case such as a multi-system customer model, a high-volume activity history, or a migration from inconsistent source systems. Use the same case throughout the roadmap so that each new topic changes or strengthens the design.
Stage two: model the requirements
Write business requirements before drawing objects. Identify entities, identifiers, relationships, ownership, lifecycle, access, reporting, retention, and integration needs. Map those requirements to Salesforce standard objects, custom fields, relationship types, or big-object considerations where appropriate.
Review the model for contradictions. A requirement for independent child ownership may conflict with a relationship choice that tightly couples ownership. A requirement for rapid reporting may conflict with storing data solely for archival access. These tensions are the substance of architecture preparation.
Stage three: add quality and governance
Define how records are created, matched, validated, corrected, approved, and retired. Assign stewardship responsibilities and document exception handling. Include organizational changes where technology alone cannot maintain data quality.
Then test the model against imperfect data. Add duplicates, missing identifiers, conflicting source values, and records that violate the preferred lifecycle. If your design has no controlled response to these conditions, it is not yet ready for enterprise use.
Stage four: test migration and scale
Create a migration sequence that preserves dependencies and supports reconciliation. Identify large objects, likely bottlenecks, indexing or query considerations, and the processes that must be paused, redesigned, or monitored during movement. Treat performance as a design requirement from the beginning rather than a troubleshooting step at the end.
Use the Query Plan Tool and query-optimization material in the official architect Trailmix to strengthen your performance reasoning. The objective is not to memorize a tool name; it is to connect access patterns and data volume to a defensible performance approach.
Stage five: rehearse architecture decisions
For each practice scenario, state the best design and explain why the alternatives are weaker. Include assumptions, risks, and the operational owner. When two options appear plausible, identify the requirement that separates them instead of choosing based on a favorite feature.
Keep an error log with three columns: missed requirement, incorrect assumption, and corrective principle. Review the principle later without rereading the entire question. This turns mistakes into reusable decision rules.
Stage six: make the scheduling decision
Schedule only after you can complete unfamiliar architecture cases without relying on memorized answer patterns. Confirm the current credential information and delivery requirements through Salesforce before booking, particularly if your study materials use the older Data Architect wording or refer to a release label that the supplied official pages do not explicitly identify.
In the final review, prioritize weak domains and cross-domain trade-offs. Avoid replacing study with exam dumps or leaked-question claims; they do not build the design judgment the credential is intended to assess and cannot guarantee a pass.
How to prepare for scenario-based decisions
Treat each question as a constrained architecture brief. Extract the business objective, data characteristics, governance expectation, and performance constraint before evaluating the answer choices. The strongest option is usually the one that satisfies the stated requirement with the fewest serious operational compromises.
A four-pass reading method
On the first pass, identify the requested outcome. On the second, mark facts about volume, source systems, relationships, ownership, and quality. On the third, eliminate choices that violate a stated constraint. On the fourth, compare the remaining designs for maintainability, governance, and scale.
Be alert to words that change the decision: authoritative, historical, independent, real-time, selective, shared, auditable, or high volume. These terms often indicate whether the question is testing modeling, integration, stewardship, or performance judgment.
Explain the trade-off, not just the feature
A useful practice answer has a short architecture rationale: the requirement favors this pattern because it preserves a particular ownership, lifecycle, access, quality, or scale behavior. Then name the cost or risk and the control that addresses it.
This method helps distinguish a familiar feature from an appropriate design. It also exposes shallow reasoning: if you cannot explain what the choice protects and what it compromises, you may be selecting by association rather than by requirement.
Common preparation mistakes
Most avoidable errors come from studying Salesforce features as isolated facts, ignoring the operating model, or confusing a technically possible design with a suitable enterprise design. Correct those habits before adding more study material.
Memorizing relationships without modeling context
Knowing the labels for master-detail and lookup relationships is not enough. Revisit ownership, dependency, lifecycle, sharing, reporting, and deletion implications. The correct relationship depends on the business behavior the model must preserve.
Treating data quality as a cleanup project
Quality is not finished when an initial load is clean. Study prevention, detection, correction, ownership, exception management, and measurement. The official expectations include organizational changes for stewardship, so include people and process in every quality design.
Ignoring source-system meaning
A migration can preserve values while damaging meaning if identifiers, definitions, units, or status codes are not reconciled. Document the source of truth and transformation rules before choosing a loading sequence.
Leaving performance until the end
Large-data-volume performance should influence the model, query pattern, integration design, and migration plan. Review indexing and query optimization alongside data shape and access patterns rather than treating them as a separate technical afterthought.
Overusing recall-based practice
Question memorization can create false confidence and does not prepare you to handle changed facts or unfamiliar requirements. Use practice to test reasoning, then verify the underlying principle in the official learning and exam-guide sources.
Delivery options and booking checks
Salesforce states that proctored certification exams can be delivered online through Pearson OnVUE or in person at a Pearson VUE testing facility. Online delivery requires a compatible device and internet connection; a testing center provides the equipment. Confirm the current booking and technical requirements directly with Salesforce before selecting an appointment.
Choose the delivery route deliberately
Choose online delivery only after checking your device, connection, room, and ability to follow the current proctoring requirements. Choose a testing center if supplied equipment or a controlled location reduces technical uncertainty. The official source establishes the two delivery routes, but current appointment details should be verified at booking.
Do not treat the delivery choice as a substitute for readiness. Use it to reduce avoidable logistical risk while keeping your preparation focused on architecture decisions.
Check the credential name before payment
The official sources reviewed identify the current credential as Salesforce Certified Platform Data Architect and do not explicitly identify a separate Salesforce Certified Data Architect (SP24) version. Match the credential shown in the official registration flow to your intended certification before you commit.
A preparation page, employer request, or catalogue label may retain older wording. That wording should not override the current official credential listing.
Group registration information
The supplied official preparation pages state that registering three or more unlocks $999 passes. If you are coordinating a team, verify the applicable terms, eligibility, and current registration flow with Salesforce rather than assuming the statement applies to an individual booking or remains unchanged.
What to do after certification
Certification is not the end of the learning cycle. Salesforce requires certified professionals to complete certification-specific Trailhead maintenance badges, and its maintenance overview states that certifications require one maintenance badge per year. Track the maintenance requirement through Salesforce so product changes do not leave the credential out of date.
Turn maintenance into architecture practice
Use each maintenance cycle to revisit one design area: data model integrity, governance, quality, migration, large-data-volume performance, or integration semantics. Update your architecture notebook with what changed and which decisions would need revalidation in a live program.
This habit is especially important for architects because a sound design depends on current platform behavior and current organizational constraints. Keep the official credential and maintenance pages as your source of truth for obligations.
Your final readiness checklist
Before booking, confirm that you can move from requirements to a defensible data architecture and explain its operational consequences. A final checklist should test application, not just recognition.
Architecture capability check
Can you map requirements to a data model using custom fields, standard objects, and appropriate relationship types? Can you explain when a big-object approach should be considered? Can you identify the authoritative source and reconcile conflicting definitions?
Can you design controls for data quality and name the people or teams responsible for stewardship? Can you plan migration sequencing, validation, relationship reconstruction, and exception handling? Can you identify large-data-volume risks, indexing considerations, query behavior, and performance trade-offs?
Can you connect security, governance, metadata, integration, persistence, and delivery into one information-architecture explanation? If any answer is vague, make that topic the next study task rather than hiding it under broad revision.
Booking and logistics check
Have you verified the official credential name and current registration information? Have you selected online Pearson OnVUE or an in-person Pearson VUE testing facility based on your actual technical and environmental conditions? Have you checked the current requirements before booking?
Once those checks are complete, set a final review boundary. Spend the remaining preparation time on weak decisions and error-log principles, not on collecting increasingly large quantities of unverified material.
Conclusion
The Salesforce Certified Platform Data Architect exam is best approached as a design judgment assessment. Build from requirements and data modeling, then add quality, governance, migration, volume, and performance considerations until you can defend the complete operating model. Use Salesforce’s current credential page, exam guide, and official Trailmixes to resolve naming and preparation questions, and verify delivery and booking details before scheduling. If you can explain both why a design fits and how the organization will sustain it, you are preparing for the capability the certification is intended to validate.