Integration-Architect
Salesforce Certified Integration Architect
Salesforce Certified Integration Architect (SP24): Exam Guide and Study Roadmap
The Salesforce Certified Integration Architect credential validates the ability to assess business and system requirements, choose suitable Salesforce APIs and integration patterns, and design secure, scalable, reliable connections with enterprise applications. It serves architects, analysts, application managers, developers, and integration specialists who make end-to-end architecture decisions. Because Salesforce currently names the credential Platform Integration Architect and the available legacy designer guide is marked Winter ’19, this guide helps you decide which official blueprint applies, what to study first, and when your preparation is strong enough to schedule.
What credential does “Salesforce Certified Integration Architect (SP24)” refer to?
Salesforce’s current credential page uses the official title Salesforce Certified Platform Integration Architect. The supplied Salesforce research does not identify an official source specifically titled “Salesforce Certified Integration Architect (SP24).” An official legacy PDF is titled Salesforce Certified Integration Architecture Designer and is marked Winter ’19. Confirm the credential name and active exam information in Salesforce’s current credential and exam-guide pages before registering.
Use the current credential page as your identity check
Salesforce describes Platform Integration Architects as experts who assess architecture environments and requirements and design sound, scalable Salesforce Platform solutions that meet end-to-end integration requirements. That description is the best current anchor for the role, while the older designer PDF can be useful only as historical context unless Salesforce directs candidates to use it for the current assessment.
Do not treat the label SP24 as proof that an older PDF is the applicable blueprint. Product releases and certification documentation can change independently. Compare the credential title, exam guide, preparation Trailmix, and any registration information immediately before you commit study time or book an appointment.
What does the certification validate?
The certification tests architecture judgment rather than isolated product recall. Salesforce expects candidates to understand Salesforce APIs and integration tools, translate needs into requirements, evaluate an existing landscape, and select appropriate APIs and integration patterns for specific scenarios. The target outcome is a defensible design that balances performance, scalability, security, reliability, operational fit, and delivery quality.
The work behind the credential
A successful architect must connect business intent to technical design. That means clarifying what data must move, which system owns it, how quickly it must be available, what happens when a destination is unavailable, and how the solution will be monitored and supported. The design also needs to remain understandable to technical stakeholders and useful to the delivery team.
Salesforce’s candidate profile includes designing high-performing, scalable, secure, and reliable integrations between the Lightning Platform and other enterprise applications. It also includes analyzing current and future-state integration architecture and maintaining the project’s Integration Architecture blueprint. Study therefore needs to cover both solution selection and the documentation and governance that make the solution implementable.
Which roles are the closest fit?
Salesforce lists Technical Architect, integration-focused System Architect, Programmer Analyst, Application Manager, Integration Architect, and Solution Architect among the typical roles. The exam is also intended for architects, analysts, and application managers who want to design secure, scalable integrations with the Lightning Platform.
The credential is a particularly sensible target when your responsibilities include integration trade-offs, interface ownership, architecture reviews, or coordination between Salesforce and enterprise platforms. It is less suitable as a first exposure to integration. Salesforce’s stated background includes 2–3 years of hands-on Salesforce administration and/or developer experience, at least 1 year supporting or implementing data-centric enterprise integration solutions, and 1–2 years of Salesforce Platform Integration Architecture experience. These are stated background expectations, not a claim that the supplied sources impose a formal prerequisite.
How is the preparation blueprint weighted?
The current preparation Trailmix assigns 28% to designing integration solutions, 23% to building the solution, and 22% to translating needs into integration requirements. It also assigns 11% to evaluating business needs and 8% to evaluating the current system landscape. Treat these as the weights shown in the current preparation resource, not as a substitute for checking the active exam guide.
Designing integration solutions — 28%
Designing integration solutions is the largest named domain in the current preparation Trailmix. Put most of your scenario practice here: compare patterns, select interfaces, define system responsibilities, and explain why a design meets nonfunctional requirements. Avoid studying tools as disconnected features. For each tool or API, ask what problem it solves, what constraints it introduces, and what alternative would be weaker in the stated scenario.
Building the solution — 23%
Building the solution is the domain assigned 23% in the current preparation Trailmix. Prepare to reason about how an approved design becomes a dependable implementation. Your notes should cover orchestration, transformation, error handling, retries, monitoring, security controls, testing, deployment coordination, and ownership. The practical recommendation is to trace each design decision into an implementation responsibility rather than memorizing a list of products.
Translating needs into integration requirements — 22%
Translating needs into integration requirements is the domain assigned 22% in the current preparation Trailmix. Practice turning vague requests such as “share customer data in real time” into explicit requirements: events or transactions, direction, data ownership, latency, volume, consistency, availability, failure recovery, auditability, and security. This step often determines the correct pattern before a particular API is considered.
Evaluating business needs — 11%
Evaluating business needs is the domain assigned 11% in the current preparation Trailmix. Do not dismiss it because its listed percentage is smaller. A technically elegant integration can still fail if it does not support the business process, service level, compliance obligations, or ownership model. Build the habit of stating the business outcome before proposing a Salesforce mechanism.
Evaluating the current system landscape — 8%
Evaluating the current system landscape is the domain assigned 8% in the current preparation Trailmix. Prepare to inventory systems, interfaces, data stores, identity boundaries, integration middleware, dependencies, and operational owners. Then distinguish the current state from the desired future state. A migration or coexistence decision should be grounded in that comparison, not in a preference for a familiar integration style.
What the weights do not tell you
The named percentages do not provide a complete description of every question or guarantee that the exam will mirror the Trailmix item by item. They are useful for allocating study effort, but official exam-guide information remains the authority for the current assessment. Keep a separate list of topics that you cannot yet explain through a scenario, even if they appear in a lower-weight domain.
Which technical topics deserve deliberate practice?
Start with architecture decisions, then use product documentation and hands-on work to test those decisions. Salesforce specifically expects API and integration-tool knowledge and the ability to select suitable APIs and patterns for given scenarios. Your preparation should therefore move from requirements to design to failure analysis, not from a catalogue of API names to unstructured memorization.
Requirements and system boundaries
For every practice scenario, write down the source of truth for each important data element. Identify whether the integration is inbound, outbound, bidirectional, synchronous, asynchronous, event-driven, batch-oriented, or a combination. Record the business trigger, consumer, expected response, data sensitivity, processing volume, timing requirement, and consequences of delay or duplication.
Then challenge the boundary assumptions. A system may be authoritative for a business process without being authoritative for every field. Separating ownership by object, attribute, or transaction helps prevent circular updates and unclear conflict resolution. This is a practical study method, not an additional Salesforce requirement: it forces you to expose the decisions that scenario questions usually test.
API and pattern selection
Build a comparison sheet for the Salesforce APIs and integration tools included in your official learning material. For each entry, record its intended use, interaction style, data shape, transaction behavior, scale considerations, security implications, and operational failure modes. Do not write “best API” without a context; write “appropriate when” and “avoid when.”
For pattern practice, begin with the business interaction and work outward. A request that needs an immediate answer has different design pressures from a large data synchronization job. A notification that many consumers may receive has different ownership and replay concerns from a tightly coupled point-to-point call. The correct answer should explain the constraint being satisfied, not simply name a fashionable pattern.
Nonfunctional requirements
Treat performance, scalability, security, and reliability as design inputs. Ask how the solution behaves during peak load, partial outage, duplicate delivery, slow downstream processing, expired credentials, malformed data, and a retry storm. Consider how sensitive data is protected in transit, at rest, in logs, and in support workflows, while keeping the design usable for authorized operators.
Reliability also includes operational clarity. Define what constitutes success, where failures are visible, who receives an alert, whether a message can be replayed safely, how reconciliation works, and which system can confirm the final state. These questions connect the architecture blueprint to the project-delivery framework Salesforce expects candidates to communicate to technical stakeholders.
Delivery and architecture governance
Salesforce says the exam evaluates fluency in communicating technical solutions to technical stakeholders and providing a project-delivery framework that supports quality and success. Prepare to explain assumptions, decisions, risks, dependencies, test evidence, release sequencing, rollback or recovery options, and ownership. An architecture document should enable implementation and review, not merely display a diagram.
Practice presenting a design in layers: business objective, requirements, context diagram, sequence or interaction flow, data ownership, security, operations, failure handling, and delivery controls. When reviewing an existing design, distinguish a genuine constraint from an inherited habit. Record open decisions and the evidence needed to close them.
How should you study when the exam name or release is unclear?
Resolve the version question before building a detailed schedule. Start with Salesforce’s current Platform Integration Architect credential page and exam guide, then compare the active preparation Trailmix with any older designer material. Use the older Winter ’19 PDF only when the current Salesforce material explicitly keeps it relevant. This prevents a polished study plan from targeting the wrong credential version.
A safe source order
Use the current credential page to confirm the official credential identity and role description. Use the Salesforce exam guide for current candidate guidance and registration information. Use the current preparation Trailmix for the available domain emphasis and learning sequence. Use Salesforce Help for the candidate profile and expected integration capabilities. Treat the legacy designer PDF as historical unless current Salesforce guidance confirms otherwise.
Keep a change log while studying. Write the page title, access date, domains shown, and topics you have covered. If the official pages disagree, pause scheduling and follow the latest authoritative registration or exam-guide instruction rather than resolving the conflict through an unofficial training provider.
A practical readiness gate
You are ready to consider scheduling when you can take an unfamiliar integration scenario, state the business goal, identify data ownership, list decisive constraints, choose and justify a pattern and API approach, describe security and failure handling, and explain how the solution will be delivered and operated. You should be able to defend the choice against a plausible alternative without relying on memorized wording.
This gate is a recommendation, not an official passing rule. The supplied research does not provide a passing score, question count, exam duration, language list, delivery method, or test-center policy. Do not use unofficial claims about those details to set your schedule or estimate your chance of passing.
What is a practical study sequence?
Use a four-stage sequence: establish the architecture model, convert it into scenario decisions, build or inspect representative integrations, and rehearse concise technical justification. The order matters. Learning individual mechanisms before understanding requirements encourages tool-first answers, while scenario practice without implementation knowledge produces designs that look plausible but cannot be operated.
Stage one: establish your baseline
Read the current official credential and exam-guide material, then mark each stated skill as confident, familiar, or weak. Include Salesforce API and integration-tool selection, business and system-landscape analysis, solution design, implementation concerns, communication, and delivery governance. Do not count a topic as strong merely because you recognize its terminology.
Create a one-page architecture vocabulary sheet. Define the integration styles and patterns in your own words, then add one suitable use case, one risk, and one selection constraint for each. The point is not to reproduce documentation; it is to build a decision framework you can use under time pressure.
Stage two: turn requirements into decisions
Work through scenarios without looking at answer keys or memorized dumps. For each one, produce a short decision record containing the objective, systems, ownership, interaction style, timing, volume, security, failure behavior, and operational owner. Then select a pattern and API or tool approach and write the reason it fits.
Afterward, deliberately change one constraint: make the response immediate, increase volume, add a sensitive field, remove middleware, or require replay. Reconsider the design. This exercise teaches the conditional reasoning the exam’s scenario focus demands and reveals whether you understand trade-offs or have simply attached one mechanism to one keyword.
Stage three: validate the design through implementation thinking
Build a small, representative lab or review a real project artefact you are permitted to use. Trace a record or business event from initiation to destination, including authentication, transformation, validation, errors, retries, logging, monitoring, and reconciliation. If you cannot implement the lab, create sequence diagrams and failure tables detailed enough that another practitioner could challenge them.
For each design, ask what happens when the receiving system accepts the request but the response is lost, when a retry creates a duplicate, or when one field fails validation. Include the recovery owner and the evidence that proves recovery. These exercises strengthen the building-the-solution domain without pretending that a lab reproduces live exam questions.
Stage four: rehearse architecture communication
Give yourself a short review session in which you explain a design to a technical stakeholder who has not seen your notes. Start with the business outcome, then cover the key requirements, selected pattern, system responsibilities, risks, security, operations, and delivery sequence. Have a colleague challenge the highest-risk assumption.
After the review, edit your architecture blueprint. Remove decorative detail that does not support a decision and add missing ownership, dependencies, failure paths, and acceptance evidence. Salesforce’s stated candidate profile includes maintaining the project’s Integration Architecture blueprint, so documentation quality belongs in preparation rather than being left to the end.
How can you divide study time across the domains?
Give the largest share of practice to designing integration solutions — 28% in the current preparation Trailmix — followed by building the solution — 23% — and translating needs into integration requirements — 22%. Reserve targeted review for evaluating business needs — 11% — and evaluating the current system landscape — 8%. Use the labels with every percentage; a bare number has no useful meaning.
A flexible allocation method
If your experience is implementation-heavy, spend extra time on business analysis, system-landscape assessment, and explaining architecture to stakeholders. If you are an architect who rarely builds integrations, reverse that emphasis by tracing designs through authentication, transformation, error handling, monitoring, and deployment. The Trailmix percentages are a starting allocation, not a reason to ignore a weak domain.
Review your error log after every study session. Categorize each miss as requirement ambiguity, pattern selection, API knowledge, nonfunctional reasoning, operational design, or communication. Study the category that caused the mistake, then solve a new scenario that changes the context. Re-reading the same explanation without applying it is a poor readiness signal.
A sample roadmap without invented calendar promises
In the first study block, confirm the current credential identity and map your baseline to the official domains. In the second, focus on requirements, business needs, and system landscape. In the third, compare patterns, APIs, and tools through altered scenarios. In the fourth, trace implementation, security, reliability, monitoring, and delivery. In the final review block, use mixed scenarios, update your blueprint notes, and verify registration details.
Set the length of each block according to your availability and baseline rather than copying a fixed calendar. The supplied official material does not establish a required preparation duration. A shorter plan can work for an experienced integration architect who has current project evidence; a longer plan is sensible when Salesforce integration architecture is new or your hands-on work is narrow.
Which study mistakes create false confidence?
The most damaging mistakes are not usually gaps in terminology; they are failures to connect a requirement to a design consequence. Watch for tool-first selection, ignoring ownership, treating synchronous behavior as automatically superior, overlooking failure recovery, and studying an old exam label without checking its current status. Correct these habits with written scenario analysis and review, not with more unstructured memorization.
Memorizing product names instead of selection logic
Knowing API names and integration tools is necessary but insufficient. A scenario can change the correct choice through timing, volume, coupling, security, data ownership, or recovery requirements. For every mechanism in your notes, add a decision rule and a counterexample. If you cannot state when another option would be better, your understanding is incomplete.
Ignoring the business process
An interface can move data accurately and still fail the business. Ask what action the integration enables, whether the consumer needs confirmation, which system resolves conflicts, and how users learn that processing has failed. Evaluating business needs is explicitly represented in the current preparation Trailmix, so business context should appear in every practice design.
Designing the happy path only
A diagram that shows only successful requests is not an integration architecture. Add timeouts, duplicate messages, invalid payloads, unavailable dependencies, authentication failure, partial completion, and reconciliation. For each condition, identify detection, retry or quarantine behavior, operator ownership, and the evidence needed to confirm the final state.
Treating the blueprint as presentation material
A polished diagram cannot replace a maintained architecture blueprint. Include assumptions, interfaces, ownership, data flows, security boundaries, dependencies, risks, and decisions still open. Update it when the future-state design changes. This practice supports both technical communication and project delivery, which Salesforce identifies as part of the assessed capability.
Relying on dumps or recalled questions
Exam dumps and leaked-question claims are not a sound preparation method and cannot establish understanding of the current credential. They may be inaccurate, unauthorized, or tied to an outdated exam version. Use official Salesforce material, legitimate hands-on learning, architecture reviews, and original scenario exercises instead. No memorization source can guarantee a passing result.
What registration and delivery information is actually evidenced?
The supplied official evidence confirms a registration incentive, not a complete delivery profile. Salesforce materials state that registering three or more unlocks $999 passes. The evidence provided here does not establish exam duration, question count, passing score, price for an individual registration, delivery method, testing locations, languages, prerequisites, or retirement status.
Check the live official guidance before paying
Use the current Salesforce exam guide and credential page to verify eligibility language, registration steps, available delivery choices, fees, scheduling rules, and any version-specific notices. Do not infer a delivery method from an older PDF or from another Salesforce certification. Details that affect cost or scheduling are time-sensitive and should be confirmed at the point of registration.
The three-or-more registration statement appears in the official preparation resources, but the surrounding commercial conditions may be updated. If you are coordinating a team, confirm that the offer applies to your intended credential and purchase route before treating it as part of the budget.
Separate background expectations from formal prerequisites
Salesforce describes a background of 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 statements help candidates judge readiness. They should not be presented as a formal prerequisite unless the current official registration guidance says so.
What should you do in the final review?
Stop expanding your notes and test decision quality. Work through mixed, original scenarios that require requirements analysis, landscape assessment, pattern and API selection, implementation reasoning, security, reliability, and stakeholder communication. Review why each alternative is weaker, then verify any time-sensitive registration information through Salesforce before scheduling.
Use a decision record, not a fact dump
For each final-review scenario, write: business outcome; systems and ownership; interaction and timing; data and security constraints; chosen pattern and Salesforce mechanism; failure and recovery behavior; monitoring and support; delivery risks; and the rejected alternative. This compact structure exposes omissions quickly and gives you a repeatable way to reason through unfamiliar wording.
Recheck weak assumptions
Look for answers that assume unlimited scale, perfect networks, one system owns all data, retries are harmless, or security ends at authentication. Replace each assumption with a question or explicit control. Also revisit terminology from any older designer material and confirm that it still belongs to the current Platform Integration Architect preparation path.
Make the scheduling decision deliberately
Schedule when your readiness gate is consistently met across mixed scenarios, not when you have merely completed a Trailmix. If you still confuse requirements with implementation choices, cannot explain failure recovery, or cannot defend ownership and security decisions, continue practicing. If the official credential information is ambiguous, resolve that administrative issue before purchasing or booking.
Where should candidates verify the details?
Use Salesforce-owned pages for the credential identity, exam guidance, preparation content, and candidate profile. The URLs below are the official sources used for this guide. Because the supplied evidence includes both a current Platform Integration Architect credential and an older Integration Architecture Designer PDF, always give current Salesforce guidance priority when the pages differ.
Recommended official reading order
Begin with the Platform Integration Architect credential page. Read the Salesforce Help candidate-profile material next, then consult the current Integration Architect exam guide. Use the preparation Trailmix to organize study and inspect the domain emphasis. Review the architect Trailmixes for additional official learning context, and use the legacy PDF only to understand historical naming unless Salesforce confirms its current applicability.
Conclusion
Treat this certification as an architecture decision assessment, not a catalogue of integration features. Confirm that you are preparing for the current Salesforce Certified Platform Integration Architect credential, use the current Trailmix weights to prioritize effort, and practise converting business needs into secure, scalable, reliable designs that can be built and operated. Your next actions are straightforward: verify the active official exam guidance, complete a baseline across the named domains, maintain an error log, and schedule only when you can justify an unfamiliar design from requirements through delivery and recovery.