Evaluate Business Needs11% of the exam
Functional and non-functional integration requirements
How to sort integration requirements into what the integration does and how well it must do it, which requirements decide timing (wait, fire, batch or events), and how to turn vague availability, cost and support wishes into measurable objectives.
Given a use case, identify functional and non-functional requirements needed for integration.
~8 min read · 9 practice questions ·
What the exam expects
- Classify a stakeholder statement as a functional requirement (what data moves and what business behavior happens) or a non-functional requirement (response time, concurrency, volume window, availability, recovery).
- Pick out the requirement that decides timing: a person waiting, an infrequent change cadence, or surges and new consumers that favor events.
- Ask the question that settles direction (which system is the source of truth) and turn "must never be down" into measurable objectives.
- Capture total cost of ownership and the maintaining team's skills as requirements.
- Key terms: functional requirement (a capability or data movement the integration must deliver); non-functional requirement (a quality the integration must meet, such as latency or availability); SLO (service level objective, a measurable reliability target); RPO / RTO (maximum acceptable data loss window / maximum acceptable downtime); source of truth (the system whose value wins and from which data flows).
Key facts
SLOs typically measure
- Detail
- Availability, latency (p50/p95/p99), throughput, error rate, recovery time
RTO vs RPO
- Detail
- RTO = maximum acceptable downtime; RPO = maximum acceptable data loss window in time
Directionality question
- Detail
- "What system should be the source of truth?" sits in the data flow area
Maintainability area
- Detail
- Maintaining team, its skills, total cost of ownership, low/pro-code debugging
Human waits for a response
- Detail
- Not a fit for event-driven architectures (asynchronous, no guaranteed response time)
Infrequently changing source data
- Detail
- Use batch patterns instead of events
Event-driven good fits
- Detail
- Surges, multiple consumers, frequent new systems or devices, IoT, offline mobile
Request and Reply vs Fire and Forget
- Detail
- Salesforce waits for completion vs hands off without waiting
Availability vs cost
- Detail
- Higher availability costs more; SLOs match investment to business need
Maintenance share of capacity
- Detail
- Typically 60–80% of development capacity for mature solutions
Sources for this section (6)
- Reliabilityarchitect.salesforce.com (opens in a new tab)
- Data Integration with Salesforcearchitect.salesforce.com (opens in a new tab)
- Event-Driven Architecturesarchitect.salesforce.com (opens in a new tab)
- Pattern Summarydeveloper.salesforce.com (opens in a new tab)
- Well-Architected Frameworkarchitect.salesforce.com (opens in a new tab)
- Resource and Cost Optimizationarchitect.salesforce.com (opens in a new tab)
- When is an event-driven design a poor fit even though the systems support events?
- Which discovery question settles data-flow direction?
- Why should an architect turn "never down" into an SLO instead of building maximum redundancy?
- What two requirements answer a CIO's worry that an integration will be costly to support after the partner leaves?
The questions are free to read. Answers with their sources and self-grading are included with the pack.
Keep reading with the Integration Architect pack
- Core concepts
- Exam traps
- Worked scenario
The pack includes:
- All 25 lessons of the Integration Architect guide, with reading progress
- Interactive decision walks and step-by-step sequence steppers
- Inline practice questions and one-click topic practice (9 questions for this lesson)
- An official source cited for every claim
- An AI tutor that answers from the guide
- Unlimited timed practice exams