Executive checklist
Use this first-pass list to expose missing decisions. The detailed sections below explain why each area matters and how to review it.
- Item 1: Name the business process and accountable product owner
- Item 2: Define users, permission boundaries and administrative roles
- Item 3: Establish authoritative systems for every shared record
- Item 4: Choose integration patterns by timing, volume and failure behavior
- Item 5: Separate configuration, Flow, Apex and external-service responsibilities
- Item 6: Plan migration, deduplication and reconciliation
- Item 7: Inventory platform limits and expected workload
- Item 8: Define environment, source, release and rollback governance
- Item 9: Test negative, bulk, exception and recovery paths
- Item 10: Prepare adoption, support, monitoring and handover ownership
How to interrogate every checklist item
Do not mark an item complete because it has been discussed. For each one, capture the five records below. This separates an informed decision from an optimistic assumption and gives delivery, security and business owners the same reference point.
- Current evidence
- What was observed, measured, reproduced or approved? Name the artifact, system or accountable source.
- Decision and boundary
- What is being chosen now, which alternative was rejected, and what remains deliberately outside this decision?
- Failure and exception path
- What can make the normal path invalid, how will people recognise it, and who may intervene or approve an exception?
- Acceptance evidence
- Which observable behaviour, test, reconciliation or owner review will prove that the implemented result matches the decision?
- Owner and review trigger
- Who owns the decision after launch, when must it be reviewed, and which product, data, threat, provider or operating change should reopen it?
Section 01
Implementation begins with process ownership
A Salesforce programme should start with the customer, sales, service or operational process that needs to improve, not a list of objects and screens. Name the owner, participants, decisions, exceptions and evidence required at each stage.
Configuration can reproduce a broken process very efficiently. Map the current flow and decide which rules should be standardized, changed or retained before translating them into platform behavior.
Section 02
Design identity and permissions deliberately
Define internal users, external users, integration identities, administrators and privileged support paths. Profiles, permission sets, roles and sharing behavior must express an approved access model rather than accumulate through troubleshooting.
Include joiner, mover and leaver workflows, delegated administration, emergency access and periodic review. Test access with representative users and negative cases, not only administrator accounts.
Section 04
Choose an integration pattern from behavior
Salesforce's official architecture guidance distinguishes request-reply, fire-and-forget, batch synchronization, remote call-in, UI update and data virtualization patterns. Timing, direction, volume, transactionality and user experience determine the useful pattern.
Do not default every connection to synchronous APIs or duplicate every external dataset. Model retries, idempotency, ordering, partial failure, rate limits and operational reconciliation before selecting middleware or custom code.
Section 05
Use the lowest sufficient customization layer
Choose standard configuration where it expresses the requirement clearly, Flow for suitable automation and Apex or external services where code-level control is justified. The goal is maintainable behavior, not a target percentage of low-code or pro-code.
Record why custom logic exists, its limits and its owner. Avoid overlapping automation that makes execution order and failure difficult to understand.
Section 06
Govern source, environments and releases
Treat metadata and code as versioned delivery assets. Define development, test and production environments, data handling, review, deployment evidence and rollback or forward-recovery for each change type.
A deployment completing successfully does not prove the business process works. Validate permissions, integrations, scheduled work, reports and high-value journeys after release, then observe errors and queue behavior.
Section 07
Test scale and failure paths
Platform limits, bulk operations and automation fan-out can make behavior differ from a small demonstration. Test representative volumes, concurrent work, integration outages, duplicates and delayed events.
Acceptance should cover user outcomes and operational recovery. Teams need to know how a failed message is found, retried or reconciled and who owns the decision when systems disagree.
Section 08
Plan adoption and day-two ownership
Define training, data stewardship, report ownership, support routing, release cadence and a governed enhancement backlog. Adoption is not guaranteed by deployment, and technical teams should not invent business-outcome claims.
Handover should identify platform accounts, licences, environments, repositories, integrations, monitoring, administrative procedures and responsible people. Review the architecture as data volume, products and integration needs change.
Decision workbook
Turn the article into a reviewable next step
The framework becomes useful when it changes a real decision. Work through these stages with the people who own the business process, data, technology and release, not only the person writing the specification.
- 01
Frame the decision
Write one sentence naming the operating problem, the people affected, the decision required now and the date or event that makes it necessary. Add explicit exclusions. If the sentence contains several independent outcomes, split the decision before evaluating solutions.
- 02
Build an evidence register
List confirmed facts, reported facts, assumptions and unknowns separately. Attach a source, owner and review date. Reproduce important technical behaviour where possible, and label estimates or illustrative examples so they cannot silently become contractual facts.
- 03
Compare viable options
Include the smallest safe change and the option to retain the current path. Compare user value, operating ownership, data and security consequences, reversibility, dependencies, cost basis and time-to-evidence. Avoid a weighted score that hides a non-waivable constraint.
- 04
Define observable acceptance
Describe successful behaviour, negative and permission cases, data reconciliation, degraded behaviour, operational visibility and owner sign-off. A feature list is not acceptance evidence; the review must show that the surrounding workflow remains safe and usable.
- 05
Sequence learning and risk
Resolve architecture-changing, data-purpose, integration, migration and authority questions before investing in low-risk polish. Deliver the smallest coherent increment that can be demonstrated and operated, then use its evidence to approve or reshape the next increment.
Failure patterns this framework is designed to prevent
A requested feature is mistaken for the underlying need
The team delivers the named screen or integration while the real decision, exception or handoff remains unresolved. Trace every material feature back to the user action and operating result it supports.
An assumption acquires the status of a fact
Repeated wording in decks, tickets and code can make an unverified belief look approved. Keep source, confidence, owner and validation action visible until evidence closes it.
The happy path hides the operating cost
Demos omit retries, corrections, access reviews, reconciliation, support and recovery. Review failure and administrative paths before declaring the design production-ready.
A technical release is treated as a business outcome
Deployment can enable an outcome; it cannot guarantee adoption, revenue, regulatory approval or operational change. Assign the non-technical actions and measure them separately.
Ownership disappears at handover
A system with no accountable owner for accounts, data, incidents, dependencies, content and future decisions degrades even when the initial build is sound. Treat ownership and review cadence as deliverables, not post-launch administration.
From guidance to delivery
How SpeedInno applies this thinking
SpeedInno uses frameworks like this to make requirements, evidence, acceptance and operating ownership visible before committing to a delivery path. The right response may be a focused assessment, a controlled implementation, a takeover plan or a decision not to build yet; the framework supports the decision rather than forcing a predetermined package.
Explore the relevant capabilityEvidence base
Primary sources
These sources support the technical framework. They do not imply endorsement of SpeedInno or a commercial partnership.
Related capability