Salesforce Certified Integration Architect (SP24) Exam Guide
The Salesforce credential currently presented by Salesforce is Salesforce Certified Platform Integration Architect. It validates the ability to assess environments and requirements, then design secure, scalable integrations across Salesforce and enterprise applications. Salesforce’s official material does not identify a current credential specifically as “SP24”; the legacy document found is titled Salesforce Certified Integration Architecture Designer and marked Winter ’19. This guide helps you decide whether your experience matches the role, which integration decisions to practise, and how to turn the available Salesforce preparation material into a focused study plan.
What credential does “Salesforce Certified Integration Architect (SP24)” refer to?
Use the current credential page as the primary reference: Salesforce calls the credential Salesforce Certified Platform Integration Architect. The available official legacy PDF uses the title Salesforce Certified Integration Architecture Designer and is marked Winter ’19, so candidates should verify the name and current exam information in Salesforce’s official certification resources before scheduling.
Salesforce describes Platform Integration Architects as people who assess architecture environments and requirements and design sound, scalable Salesforce Platform solutions that meet end-to-end integration requirements. That description is more useful than treating the exam as a catalog of API definitions: it points toward scenario-based architecture judgement, trade-offs, and communication.
How to handle the SP24 label
Treat “SP24” as the label used for your target page or study catalogue, not as independently verified evidence of a Salesforce exam release. Do not assume that a legacy exam guide, an older blueprint, or an unofficial question bank describes the current credential. Start with the current credential page and exam guide, then check the registration workflow for the version offered to you.
Who should consider this exam?
This exam is aimed at architects, analysts, and application managers who design secure, scalable integrations with the Lightning Platform. Salesforce lists Technical Architect, integration-focused System Architect, Programmer Analyst, Application Manager, Integration Architect, and Solution Architect among relevant roles. The practical question is whether you already make cross-system design decisions, not whether your job title contains the word architect.
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 experience expectations, not a claim that every candidate must document them as a formal prerequisite.
A strong fit is someone who can explain why one integration approach is appropriate for a business and technical context, identify risks in an existing landscape, and maintain an architecture blueprint as delivery progresses. Someone who has only configured isolated point-to-point connections may need to build broader architecture reasoning before booking the exam.
A quick readiness test
Before committing to a date, take a representative business requirement and write a short design decision. Identify systems of record, data ownership, direction of exchange, timing, failure handling, security boundaries, monitoring, and change ownership. If your answer names a tool without explaining these constraints, study architecture analysis before memorizing product terminology.
Then explain the design to two audiences: an integration developer who needs implementation direction and a business stakeholder who needs confidence about risk and outcomes. Salesforce explicitly includes communication with technical stakeholders and a project-delivery framework that supports quality and success, so communication should be part of preparation rather than an afterthought.
Which skills receive the most preparation emphasis?
The current Salesforce preparation Trailmix assigns 28% to designing integration solutions, 23% to building the solution, and 22% to translating needs into integration requirements. Those three exam domains together deserve the largest share of study time because they require connected reasoning: understand the need, choose an architecture, and turn it into a workable solution. Treat these weights as the current Trailmix’s preparation emphasis, not as an unsupported reconstruction of an SP24 question count.
The current preparation Trailmix assigns 11% to evaluating business needs and 8% to evaluating the current system landscape. These domains are smaller in the published Trailmix emphasis, but they influence every later decision. A technically elegant design can still fail if the business outcome, existing constraints, ownership model, or data landscape was misunderstood.
Use the domain labels with their weights when planning, and do not compare bare percentages. In particular, do not interpret the 28% for designing integration solutions as a guarantee about the percentage of questions on a current exam. Confirm the active exam guide before final scheduling.
What “designing integration solutions” means in practice
Practise moving from requirements to an end-to-end design. For each scenario, decide which system owns the data, whether the interaction is synchronous or asynchronous, what initiates the exchange, how consumers are identified, and how the design behaves when a dependency is unavailable. Then record the reason for rejecting plausible alternatives.
A useful design note should cover data movement, transaction boundaries, error recovery, observability, security, performance, scalability, and operational ownership. The goal is not to draw the most elaborate diagram. It is to make assumptions visible and show how the design remains reliable as volume, consumers, or business rules change.
What “building the solution” means in practice
Building knowledge is broader than recalling API names. Salesforce expects candidates to understand Salesforce APIs and integration tools and select suitable APIs and integration patterns for given scenarios. Study each option through its fit, limitations, authentication implications, data behavior, failure handling, and operational consequences.
For every tool or pattern you review, create a comparison card with five prompts: best-fit use case, unsuitable use case, coupling introduced, failure behavior, and monitoring approach. This forces you to select based on evidence in a scenario instead of choosing the first familiar mechanism.
Why requirements and landscape analysis matter
Requirements analysis determines what the integration must achieve; landscape analysis determines what the organization can safely support. Practise separating business objectives from proposed solutions, documenting nonfunctional requirements, and identifying systems, interfaces, data stores, identity boundaries, integration owners, and existing constraints before selecting a pattern.
Include future-state reasoning. Salesforce’s candidate profile includes analyzing existing and future-state integration architecture and maintaining the project’s Integration Architecture blueprint. Study how a design decision should be recorded, reviewed, and updated when scope, systems, or constraints change.
How should you study Salesforce APIs and integration patterns?
Start with decisions, not a list of products. For each scenario, establish interaction style, timing, volume characteristics, data consistency needs, ownership, security, and recovery expectations. Only then compare the Salesforce API or integration tool that satisfies those conditions. This sequence reflects Salesforce’s expectation that candidates select appropriate APIs and patterns for given scenarios.
Build a matrix whose rows are scenario constraints and whose columns are candidate approaches. Mark whether each approach supports the required interaction style, data shape, scale, security model, retry behavior, and monitoring. Leave a written reason for every rejected option. Reviewing those rejections is often more valuable than rereading a tool description.
Use official Salesforce learning and reference material for terminology and current behavior. The official preparation Trailmix and the Integration Architecture Trailmix are useful starting points, but a Trailmix is not permission to ignore the active exam guide or product documentation.
A repeatable scenario method
Read the business outcome first and underline words that imply constraints: immediate, eventual, confidential, high volume, recoverable, auditable, or near real time. Translate each word into a design question. For example, “immediate” should prompt a conversation about response dependency and timeout behavior, while “auditable” should prompt traceability and retention questions.
Next, map ownership and direction. Ask which system creates, updates, and validates the record; whether Salesforce is a source, target, or participant; and what happens when two systems disagree. Then test the proposal against failures, duplicate messages, partial completion, authentication changes, and version changes.
Finally, state the decision in one sentence and justify it with the constraints. If you cannot explain why the alternative is weaker, the decision is not yet ready.
Topics to connect rather than memorize separately
Connect API selection with limits, data volume, transaction boundaries, and error recovery. Connect security with identity, least privilege, secrets, trust boundaries, and operational access. Connect reliability with retries, idempotency, dead-letter handling, alerting, and reconciliation. Connect scalability with burst behavior, asynchronous work, dependency isolation, and capacity planning.
Also connect architecture to delivery. A design needs ownership, interface contracts, deployment sequencing, test data, rollback or compensation decisions, monitoring, and support procedures. Salesforce’s stated candidate profile combines solution design with maintaining an Integration Architecture blueprint, so study artefacts and governance as part of the technical answer.
What should a practical study roadmap look like?
Use a staged roadmap that moves from assessment to design, implementation reasoning, and timed decision practice. Spend the first stage identifying gaps, the middle stages building scenario fluency, and the final stage validating that you can explain a complete architecture under time pressure. Adjust the pace to your experience; the sequence matters more than an invented calendar.
Keep one working portfolio throughout preparation: a landscape sketch, requirements checklist, pattern decision matrix, security review, failure-handling table, and concise architecture decision records. Revisit the same artefacts as your understanding improves. This gives you a way to see whether you are learning principles or merely collecting notes.
Stage 1: establish your baseline
Read the current official exam guide and credential page, then compare their terminology with the study material you already use. Record what you can explain without notes: business requirements, landscape assessment, API selection, integration patterns, security, reliability, scalability, and delivery communication.
Complete a self-assessment using scenarios rather than flashcards. For each weak area, label the problem as vocabulary, product behavior, architecture reasoning, or communication. The label determines the remedy: reference reading for vocabulary, hands-on validation for behavior, design drills for reasoning, and short presentations for communication.
Stage 2: study the domains in dependency order
Begin with evaluating business needs and the current system landscape. Without those inputs, pattern selection becomes guesswork. Move next to translating needs into integration requirements, including functional and nonfunctional requirements, ownership, data quality, security, availability, and operational responsibilities.
Then concentrate on designing integration solutions, followed by building the solution. For every design, produce an implementation-aware explanation: interfaces, contracts, authentication, deployment dependencies, monitoring, retries, reconciliation, and support ownership. Finish each exercise by explaining the design to a technical stakeholder and identifying the trade-off that needs approval.
Stage 3: practise complete case decisions
Use original case studies that you create from ordinary enterprise situations, such as customer synchronization, order updates, identity exchange, or event notification. Do not use leaked questions or exam dumps. They cannot establish current coverage, and memorizing purported answers does not develop the judgement the role requires.
For each case, write the assumptions before the solution. Include a current-state summary, target state, system-of-record decision, interaction pattern, API or tool choice, security controls, failure path, observability plan, and delivery risks. Ask a peer to challenge one assumption and revise the architecture record rather than defending the first design automatically.
Stage 4: decide whether to schedule
Schedule only when you can consistently move from ambiguous requirements to a defensible design and explain the operational consequences. Your final review should use the active Salesforce exam information, because the available evidence does not verify every delivery detail for an SP24-labelled exam.
Before registering, confirm the credential title, exam availability, delivery options, policies, and any current pricing or scheduling terms directly with Salesforce. The supplied official pages state that registering three or more can unlock $999 passes, but they do not establish that this offer applies to every candidate or scheduling situation. Treat it as a Salesforce offer to verify, not as a personal budgeting assumption.
How can you practise architecture communication?
Practise concise decisions supported by explicit constraints. A good answer identifies the requirement, states the design, explains why it fits, names the main risk, and describes how delivery and operations will control that risk. This mirrors Salesforce’s emphasis on communicating technical solutions to technical stakeholders and providing a project-delivery framework that supports quality and success.
Use a two-layer explanation. The first layer is a short architecture decision for review meetings. The second is an implementation note containing interfaces, data behavior, security, testing, deployment, monitoring, and support responsibilities. This prevents either extreme: a diagram with no operational detail or a technical catalogue with no business rationale.
During peer review, ask reviewers to challenge assumptions about ownership, timing, failure recovery, access, and future change. Do not ask only whether the diagram looks correct. Ask what breaks first, who receives the alert, how a duplicate is handled, and how the team proves that the integration delivered the intended business result.
A compact architecture review checklist
Can the design state the business outcome and measurable acceptance conditions? Can it identify the source of truth for each important data element? Are interaction timing, transaction boundaries, and data contracts explicit? Does the design explain authentication, authorization, secret handling, and trust boundaries?
Can an operator detect failure, distinguish transient from permanent errors, retry safely, and reconcile missed or duplicated data? Are dependencies, deployment order, testing responsibilities, and support ownership documented? Can the design evolve without forcing every consumer to change at once? Any unanswered question becomes a targeted study task.
Which preparation mistakes waste the most time?
The most expensive mistake is memorizing product names without learning selection criteria. Other common problems include studying only the largest domain, ignoring business and landscape analysis, treating synchronous interaction as automatically superior, and leaving monitoring and recovery until the end. Correct these by requiring every study answer to include constraints, trade-offs, and operational behavior.
Do not treat an old official PDF as proof of current SP24 coverage. The available legacy document is marked Winter ’19, while Salesforce’s current credential page uses Platform Integration Architect. Use older material for concepts only after checking whether terminology and product behavior remain current.
Do not convert study percentages into a promised question distribution. The 28% for designing integration solutions, 23% for building the solution, 22% for translating needs into integration requirements, 11% for evaluating business needs, and 8% for evaluating the current system landscape are labels and weights from the current preparation Trailmix. Keep each percentage attached to its domain and confirm the active guide.
Do not use dumps, leaked questions, or answer memorization as a substitute for preparation. Besides being unreliable for a changing credential, that approach leaves you unable to reason through a modified scenario or explain a decision to a stakeholder. Use fresh cases and official material instead.
What to do when two answers seem plausible
Return to the requirement that distinguishes them. Identify the deciding constraint, such as response dependency, data ownership, volume, security, recovery, or operational accountability. If the scenario does not supply enough information, state the assumption that makes your choice valid and note what clarification you would request.
Then eliminate options that solve the immediate interaction but create unacceptable coupling, failure propagation, governance overhead, or support risk. Architecture questions often reward the answer that satisfies the whole operating context, not the one that uses the most technically familiar Salesforce feature.
Which official resources should anchor your preparation?
Use Salesforce’s current credential page and exam guide to verify the credential name and any current scheduling information. Use the Salesforce Help material for the candidate profile, expected experience, API and integration-tool expectations, and communication emphasis. Use the current preparation Trailmix to organize study domains, then supplement it with official product documentation and hands-on validation where the scenario requires product behavior.
The Architect Trailmix Master can provide broader architecture context, while the Integration Architecture Designer Trailmix and the integration-focused architect Trailmix provide additional learning paths. Because the supplied pages include both current and legacy naming, compare dates and titles before relying on any older module or document as current exam policy.
Keep a source log with the page title, access date, and the decision or concept it supports. When a note conflicts with the active exam guide, the current official Salesforce source should control.
A final evidence check before booking
Verify the current official credential title, the exam guide linked to that credential, registration and delivery information, and any applicable commercial terms. The supplied research does not establish exam duration, question count, passing score, languages, delivery method, or retirement status, so do not plan around figures from unofficial pages or older PDFs.
If your preparation provider labels the target “Salesforce Certified Integration Architect (SP24),” ask how that label maps to Salesforce’s current Platform Integration Architect credential. Record the answer before paying or scheduling. This small check can prevent preparation against the wrong version or credential family.
What should you do next?
Start with the current Salesforce credential and exam-guide pages, write down the official title shown there, and build a gap list against the five weighted domains in the current preparation Trailmix. Choose one realistic integration case and produce a complete decision record. That first artefact will reveal whether your next step is product study, architecture practice, or communication rehearsal.
After reviewing the case, select a small set of official learning items that address the gaps rather than completing material indiscriminately. Rework the case, test the failure path, and explain the design to another technical person. Repeat until your decisions are constraint-led and operationally credible.
Only then check current registration and delivery details and choose a date that leaves room for a final review of the active official guide. Preparation is ready when you can justify an integration architecture, not merely recognize terminology or recall a supposed answer.
Conclusion
The credential is best approached as an architecture decision exam: understand the business and landscape, translate them into requirements, select APIs and patterns deliberately, and show how the solution remains secure, scalable, reliable, and supportable. Because Salesforce’s current name is Platform Integration Architect and the supplied evidence does not verify a distinct SP24 edition, confirm the live official details before scheduling. Use the Trailmix weights to prioritize effort, but let scenario practice and evidence-based design decisions determine readiness.
