Integration-Architect
Salesforce Certified Integration Architect
Salesforce Certified Integration Architect (SP24) Exam Guide
This exam validates the architecture judgment needed to connect Salesforce with enterprise applications through secure, scalable, reliable integration designs. It is aimed at architects, analysts, application managers, and experienced Salesforce professionals who must turn business and system constraints into an executable integration approach. Salesforce currently presents the credential as Salesforce Certified Platform Integration Architect, while the supplied research does not identify an official credential specifically named “SP24.” This guide helps you decide whether your experience matches the target profile, which capabilities deserve study time, and how to prepare through architecture decisions rather than memorized product facts.
What credential should you verify before scheduling?
The safest first step is to confirm the credential name and the current exam information in Salesforce’s official credential and exam-guide pages. The current credential page uses “Salesforce Certified Platform Integration Architect,” whereas the supplied official research does not identify a credential specifically titled “Salesforce Certified Integration Architect (SP24).”
paragraphs
Why the SP24 label needs checking
The supplied official research found a legacy Salesforce document titled “Salesforce Certified Integration Architecture Designer,” marked Winter ’19. It also found that Salesforce’s current credential page uses “Platform Integration Architect.” That difference matters because an older study guide, a seasonal label, or a catalogue name may not represent the current registration or preparation requirements.
Treat “SP24” as a catalogue or version reference until Salesforce confirms it on the page you use to schedule. Do not assume that a legacy PDF is the current exam blueprint. Open the current credential page and the current Salesforce exam guide, compare the title and scope, and save the official links you used for your preparation plan.
What decision this creates for a candidate
If your registration page shows Platform Integration Architect, align your preparation to that current credential rather than searching for a separate SP24 exam. If the registration flow shows a different title or version, resolve the discrepancy with Salesforce before paying or booking. This simple check prevents studying an outdated designer guide as though it were a current blueprint.
Who is the exam designed for?
The exam is intended for architects, analysts, and application managers who design secure, scalable integrations with the Lightning Platform. Salesforce also lists Technical Architect, integration-focused System Architect, Programmer Analyst, Application Manager, Integration Architect, and Solution Architect among typical roles. The common thread is responsibility for integration decisions, not a particular job title.
This audience is expected to reason across Salesforce and external systems. The work includes assessing environments and requirements, selecting APIs and integration patterns, designing reliable solutions, and maintaining an Integration Architecture blueprint. A candidate who knows individual Salesforce features but cannot explain trade-offs between systems should treat architecture practice as a priority.
Salesforce’s stated background includes 1–2 years of Salesforce Platform Integration Architecture experience, 2–3 years of hands-on Salesforce administration and/or developer experience, and at least 1 year supporting or implementing data-centric enterprise integration solutions. These are Salesforce’s candidate-profile expectations, not additional prerequisites that this guide can independently verify. Use them as a readiness benchmark rather than as a reason to count experience mechanically.
The profile is particularly relevant if your current work involves enterprise applications, data movement, API selection, integration governance, or future-state architecture. It is less suitable as a first Salesforce credential for someone who has not yet worked with platform configuration, development, or integration delivery. In that situation, build foundational experience before relying on an architect-level exam plan.
A practical readiness test
Before scheduling, write a short architecture explanation for a Salesforce-to-enterprise integration without looking up the answer. Include business purpose, data ownership, direction of flow, timing, failure handling, security, monitoring, and operational ownership. If you can defend the design and identify its compromises, you are closer to the intended profile. If your answer is only a list of APIs, study requirements analysis and architecture trade-offs first.
Ask a second practitioner to challenge assumptions such as system of record, retry behavior, duplicate handling, volume, and change ownership. The exercise is more useful than asking whether you have seen a named tool. Architects are evaluated on selecting an appropriate approach for a scenario, not on reciting product names in isolation.
Which skills does the preparation outline emphasize?
The current preparation Trailmix assigns 28% to designing integration solutions, 23% to building the solution, 22% to translating needs into integration requirements, 11% to evaluating business needs, and 8% to evaluating the current system landscape. These figures come from the preparation Trailmix and should be used to prioritize study, not treated as a complete replacement for the current official exam guide.
Designing integration solutions is the largest named area in that current preparation Trailmix. Study architecture selection: how requirements, constraints, ownership, security, reliability, and scale lead to a particular pattern. Building the solution follows closely, so connect design decisions to implementation concerns such as API behavior, error processing, deployment, testing, and operational support.
Translating needs into integration requirements requires more than collecting field mappings. Convert business goals into explicit requirements for data ownership, latency, consistency, availability, transaction boundaries, privacy, auditability, recovery, and support. Then identify which requirements conflict. A design that meets speed but cannot recover safely, for example, is not complete.
Evaluating business needs and evaluating the current system landscape receive smaller assignments in the current preparation Trailmix, but they are not optional preliminary tasks. They determine what the integration must accomplish and what constraints already exist. Do not interpret a smaller percentage as permission to skip them; use them to frame the higher-weight design and build decisions.
How to use the weights without overfitting
Start with the two largest areas, then use requirements and landscape assessment to make your practice scenarios realistic. Allocate additional time to any area where you cannot produce a defensible design. A percentage tells you where the Trailmix places emphasis; it does not tell you that every question will be predictable or that memorizing a weighting produces a pass.
Keep the official domain label attached to each percentage in your notes. Write “28% designing integration solutions,” not simply “28%,” and write “23% building the solution,” not simply “23%.” This avoids confusing the domains when reviewing your study progress.
How should you study the integration architecture domains?
Study each domain as a decision sequence: clarify the business outcome, inspect the landscape, express measurable integration requirements, design the target architecture, and explain how it will be built and operated. That sequence mirrors the work of an integration architect and gives you a repeatable method for scenario-based questions.
For evaluating business needs, practice separating a requested feature from the underlying outcome. A request for real-time synchronization may actually require timely visibility, while a request for a shared customer record may conceal ownership and governance problems. Identify stakeholders, business events, critical data, compliance constraints, service expectations, and consequences of delay or failure.
For evaluating the current system landscape, inventory systems, interfaces, data stores, authentication boundaries, integration platforms, existing contracts, batch processes, custom code, and operational responsibilities. Mark assumptions that need validation. An attractive future-state design can fail if it ignores an existing dependency, an undocumented transformation, or a system that cannot support the proposed interaction style.
For translating needs into integration requirements, turn the inventory and business outcome into testable statements. Define what moves, who owns it, when it moves, what happens when it is rejected, how duplicates are treated, and how operators know that processing is healthy. Include nonfunctional requirements rather than leaving security, scale, and reliability until implementation.
For designing integration solutions, compare alternatives against those requirements. Consider synchronous and asynchronous behavior, request and event flows, orchestration and choreography, point-to-point and mediated connections, data replication and on-demand access, and the location of transformation and validation. The best answer is the one that satisfies the scenario with acceptable complexity and operational risk.
For building the solution, think beyond the happy path. Plan authentication, authorization, input validation, idempotency, retry and dead-letter handling, transaction boundaries, logging, alerting, testing, deployment, versioning, and rollback. Also ask who owns each operational action. A design that works in a demonstration but cannot be diagnosed or recovered is unfinished.
A repeatable scenario worksheet
Use one page for each practice scenario with these fields: business outcome; source and target systems; data owner; direction of movement; timing; volume and growth assumptions; consistency requirement; security boundary; failure and recovery behavior; monitoring; and rejected alternatives. Fill the page before choosing a Salesforce API or integration pattern. This keeps the tool from becoming the starting point.
After choosing an approach, write a short rationale using “because” statements. For example, connect asynchronous processing to a stated requirement for decoupling or resilience, not to a generic belief that asynchronous designs are always better. Then name the cost: delayed visibility, more operational state, or additional reconciliation. Architecture judgment includes acknowledging the trade-off.
The communication skill behind the technical answer
Salesforce says the exam evaluates fluency in communicating technical solutions to technical stakeholders and providing a project-delivery framework that supports quality and success. Practice presenting the same decision at two levels: a concise recommendation for a stakeholder and a deeper explanation for an implementation team.
A useful explanation identifies the decision, the requirement driving it, the principal risk, the control that reduces that risk, and the condition that would make you revisit the choice. Avoid presenting a catalogue of features without a recommendation. Technical stakeholders need to understand why the architecture is suitable and how the project will prove that it works.
What Salesforce APIs and tools should you review?
Salesforce expects candidates to understand Salesforce APIs and integration tools and to select appropriate APIs and integration patterns for given scenarios. Study selection criteria rather than isolated definitions: interaction style, data shape, transaction needs, volume, timing, security, limits, error behavior, and operational ownership should all influence the choice.
Build a comparison sheet from current official Salesforce documentation. For every API or tool you study, record its intended use, the type of interaction it supports, important constraints, authentication considerations, failure behavior, and the scenario in which another option would be more appropriate. Keep the sheet linked to current documentation because product capabilities and limits can change.
Use Trailhead’s current Platform Integration Architect preparation Trailmix as the organizing spine for learning. The Trailmix can expose you to relevant modules and topics, but completing a module is not the same as being able to defend an architecture. After each learning unit, create or update a scenario worksheet and explain the design aloud.
The supplied research also includes Salesforce’s Integration Architecture Designer Trailmix and the broader Architect Trailmix. Use them as supplemental learning paths when a topic needs reinforcement. Do not allow a broad architect curriculum to dilute the integration focus: requirements, APIs, patterns, reliability, security, and delivery decisions remain the center of this exam preparation.
A better way to memorize API choices
Replace flashcards that ask only “What is this API?” with contrast questions: Which requirement makes this option suitable? What would disqualify it? Where does transformation occur? What happens if the target is unavailable? How is a duplicate prevented? What evidence would prove the integration is healthy? These prompts test selection and consequences rather than vocabulary.
Revisit every comparison when a scenario changes one constraint. If timing changes, if the external system becomes the system of record, if the payload grows, or if a transaction must remain atomic, reconsider the design. The ability to change your recommendation when a requirement changes is more valuable than memorizing one preferred pattern.
How can you turn experience into exam-ready practice?
Use architecture cases that force a choice and require a written rationale. For each case, produce a current-state sketch, a future-state design, an interface inventory, a decision record, and an operational model. This converts practical experience into evidence of the skills measured by the preparation outline.
Choose cases with different pressures: a customer data exchange, an order or service process, event-driven notifications, a legacy batch dependency, and a high-sensitivity data flow. The point is not to reproduce live exam questions. It is to exercise the reasoning patterns that Salesforce describes: assessing environments and requirements, selecting APIs and patterns, and designing high-performing, scalable, secure, and reliable integrations.
After drafting, perform a failure review. Remove the network, make the source send the same message twice, reject part of a payload, change a field contract, expire credentials, or make processing slower than expected. Document the resulting behavior and the operator’s next action. If the design has no answer, revise it before moving on.
Then perform a stakeholder review. Explain what the integration does, what it deliberately does not do, which system owns each data element, how failures are surfaced, and what the project must test. Ask whether a nontechnical stakeholder could identify the business consequence of an outage. Ask whether an implementation team could identify the acceptance evidence.
A four-pass review method
First pass: assess requirements and assumptions. Second pass: compare patterns and API choices. Third pass: test security, resilience, scale, and operations. Fourth pass: communicate the recommendation and delivery framework. Keeping these passes separate helps reveal a common mistake: selecting a technically possible interface before understanding the business and landscape constraints.
For every rejected alternative, write one reason tied to the case. This prevents vague statements such as “not scalable” or “less secure.” Specify which requirement, risk, or operational burden makes the alternative weaker. The explanation itself becomes a study note for later review.
What common preparation mistakes should you avoid?
The most damaging mistake is treating the exam as an API-name quiz. Salesforce explicitly expects candidates to select appropriate APIs and integration patterns for given scenarios, so study the reasoning around selection, constraints, and consequences. A list of definitions will not show whether you can design a solution.
Another mistake is starting with the preferred Salesforce tool. Start with business outcome, system landscape, ownership, timing, consistency, security, and failure requirements. Only then compare tools and patterns. This prevents a familiar implementation technique from dictating an architecture that does not fit.
Do not design only the successful transaction. Include retries, duplicate messages, partial failures, unavailable dependencies, malformed data, contract changes, and reconciliation. Reliable integration is an operating capability, not merely a connection that succeeds when every dependency is healthy.
Do not ignore communication and delivery. The exam evaluates communication to technical stakeholders and a project-delivery framework that supports quality and success. Include testing responsibilities, acceptance evidence, deployment sequencing, monitoring, support ownership, and change control in your practice designs.
Do not treat the current preparation Trailmix percentages as a promise about the exact distribution of questions. Use the labels and percentages to prioritize, then verify the current official exam guide. In particular, do not drop the lower-assigned areas: business needs and system landscape provide the facts on which sound design depends.
Finally, do not use leaked questions, exam dumps, or memorization claims as a substitute for competence. They cannot establish that you can evaluate a landscape, defend a design, or support delivery, and relying on them risks preparing against outdated or inaccurate material.
Warning signs that your plan is too shallow
Your plan needs more depth if every practice answer recommends the same pattern, if you cannot state the system of record, if security is a final paragraph rather than a design constraint, or if failures are handled with “retry” and no limits or operator path. It also needs work if you can name a tool but cannot explain why its alternative is unsuitable.
Another warning sign is studying only reading material. Architecture decisions improve through written comparison and review. Schedule time to produce diagrams or structured notes, defend them, and revise them after introducing a changed requirement. That cycle reveals gaps that passive familiarity hides.
What is a practical study roadmap?
Use a staged roadmap that moves from scope confirmation to domain coverage, then to scenario practice and readiness review. The sequence below is a recommendation, not an official Salesforce schedule. Adjust the pace to your existing integration experience, but do not skip the diagnostic and final verification steps.
The roadmap deliberately begins with the current credential information because the supplied research distinguishes the current Platform Integration Architect title from a legacy Integration Architecture Designer document and does not verify an official “SP24” designation.
Stage 1: confirm the target and establish a baseline
Open the current Salesforce credential page and exam guide. Record the official title, current scope, registration information, and any delivery details presented there. Then complete a baseline case without reference material. Score yourself by capability: requirements, landscape, design, build and operations, and communication. Do not use an invented pass threshold; use the baseline to decide where your first study block belongs.
Create a source folder containing the current official pages and the Trailhead preparation resources. Mark the legacy Winter ’19 PDF as historical context rather than automatically treating it as current. This keeps your notes traceable and reduces the risk of mixing old and current guidance.
Stage 2: map requirements and the landscape
Practice business interviews and system inventories. For several cases, write the outcome, stakeholders, ownership, timing, consistency, security, scale assumptions, and operational consequences. Draw current-state and future-state views, even if the diagram is simple. Your goal is to make hidden constraints visible before choosing an interface.
At the end of this stage, review the 11% evaluating business needs domain and the 8% evaluating the current system landscape domain in the current preparation Trailmix. Keep the labels with the percentages in your notes. The practical checkpoint is not recall of those figures; it is whether you can explain how each assessment changes the target architecture.
Stage 3: compare APIs and integration patterns
Build the API and pattern comparison sheet from current Salesforce documentation and Trailhead study. Work through contrasting scenarios and change one requirement at a time. For each recommendation, record timing, data ownership, transaction behavior, security, error handling, monitoring, and the principal trade-off.
Use the 22% translating needs into integration requirements domain as the bridge between analysis and design. If your API selection feels instinctive, return to the requirements and write the explicit condition that supports it. A defensible choice should be explainable to another architect without relying on familiarity or authority.
Stage 4: design, build, and operate complete solutions
Give the 28% designing integration solutions domain and the 23% building the solution domain the largest share of your practice attention in line with the current preparation Trailmix. For each case, produce a target architecture, interface decisions, security approach, failure model, monitoring plan, testing strategy, deployment considerations, and support ownership.
Include at least one review in which an external system is unavailable and another in which duplicate or invalid data arrives. Explain how the system avoids silent loss, how processing resumes, and how people identify unresolved records. Then revise the design when a requirement changes. This is where architecture knowledge becomes usable judgment.
Stage 5: rehearse communication and verify readiness
Present each final design as a recommendation rather than a lecture. State the business outcome, the chosen approach, the decisive requirements, the material risks, the controls, and the delivery evidence. Have a reviewer challenge the assumptions and ask what would cause a different design.
Return to Salesforce’s current official exam information before scheduling. Confirm that your preparation matches the credential you intend to take and check the registration and delivery information shown there. Schedule when your baseline cases consistently produce complete, defensible designs, not merely when you have finished a list of modules.
How should you use Salesforce’s official resources?
Start with the current Platform Integration Architect credential page and the Salesforce exam-guide page for authoritative credential and registration context. Use the Help article for the candidate profile, role expectations, experience background, communication emphasis, and API and pattern selection expectations. Use Trailhead Trailmixes to structure learning and the legacy PDF only with careful attention to its historical title and date.
The supplied official resources serve different purposes. The credential page establishes the current name and positioning. The Help article describes the intended candidate and evaluated capabilities. The current preparation Trailmix supplies the domain emphasis used in this guide. The broader Architect Trailmix and other integration-focused Trailmix can fill learning gaps. The legacy developer PDF may provide useful historical context, but the supplied research does not establish it as the current SP24 blueprint.
When a resource contains details that can change, verify them at the point of scheduling or final review. This is especially important for registration, delivery, and any version-specific exam information. Keep a note of the page title and access context in your study record so you can identify which guidance was current when you prepared.
A source-disciplined note-taking format
For each note, separate three labels: official requirement, official capability or domain emphasis, and practical recommendation. For example, Salesforce’s expectation that candidates select appropriate APIs and patterns is an official capability; writing a comparison table before choosing a tool is a preparation recommendation. Keeping those categories separate prevents your own study method from being mistaken for an exam rule.
Attach the relevant official URL to claims that may change. Do not copy unsupported delivery assumptions from third-party pages into your schedule. If the official page does not state a detail in the material available to you, record it as unverified and check Salesforce directly rather than filling the gap with a guess.
What should you do before booking?
Before booking, verify the current credential title, review the current official exam guide, assess your experience against Salesforce’s stated background, and complete several end-to-end architecture cases. Confirm that you can explain requirements, landscape, API and pattern selection, security, reliability, operations, and delivery to a technical stakeholder.
Check the official registration page for current delivery and scheduling information rather than relying on a catalogue label. The supplied research does not provide enough evidence to state the exam’s delivery method, duration, question count, language options, passing score, or other scheduling details. Those omissions should lead to verification, not assumptions.
If your organization is registering candidates, the supplied official Trailhead pages state: “Register three or more to unlock $999 passes.” Treat that as an official promotional or registration condition tied to the cited pages, and confirm the current terms before making a purchasing decision. Do not generalize it to individual registration or assume it remains unchanged.
Prepare a final review sheet with your recurring weaknesses, the official source links, and a short decision framework. Stop adding unrelated topics once the sheet is stable. Spend the remaining preparation time on cases that expose weak reasoning, especially cases where requirements conflict or operational failure is more important than the initial data transfer.
A final readiness checklist
You are better positioned to schedule when you can identify the business outcome and data owner; describe the current and future-state landscape; convert needs into explicit integration requirements; compare APIs and patterns against those requirements; address security, scale, reliability, and failure recovery; outline build and delivery controls; and communicate the recommendation with its trade-offs.
You should also be able to explain what evidence would demonstrate success after implementation. That may include functional behavior, security controls, monitoring signals, recovery tests, reconciliation results, and stakeholder acceptance. The exact evidence depends on the scenario, but the habit of defining it is central to responsible architecture.
If one of these capabilities remains weak, delay booking long enough to practice it deliberately. A completed Trailmix is useful evidence of study activity, but it is not by itself proof that you can make and defend integration architecture decisions.
Where does this preparation lead after the exam?
The credential’s practical value is tied to the work it represents: assessing architecture environments and requirements, designing sound and scalable Salesforce Platform solutions, and meeting end-to-end integration requirements. Preparation therefore has value beyond a test date when it improves the quality of your decision records, implementation guidance, and operational designs.
Keep the architecture blueprint current as projects change. Revisit system ownership, interface contracts, security boundaries, monitoring, and recovery assumptions after major releases or changes in external applications. This is a practical extension of the candidate profile’s emphasis on analyzing existing and future-state architecture and maintaining the project’s Integration Architecture blueprint.
The strongest next action is specific: choose one integration you know, rewrite its requirements and failure model, compare its current approach with a defensible alternative, and present the decision to a technical stakeholder. Then use the official Salesforce pages to confirm the credential and booking details before you schedule.
Conclusion
Prepare for this exam as an architecture decision exercise, not as a catalogue of Salesforce interfaces. Confirm whether the credential you intend to take is the current Platform Integration Architect exam, use the current official guide and Trailhead preparation resources, and organize practice around business needs, landscape assessment, requirements, design, build, operations, and communication. The current preparation Trailmix gives the strongest emphasis to designing integration solutions and building the solution, but those areas depend on accurate requirements and system understanding. Book only after your case-based reviews show that you can justify a secure, scalable, reliable design and explain how a project will deliver and support it.