---

name: salesforce-architecture-variants description: 'Analyze Salesforce direct API, middleware, event-driven, replicated-data, and hybrid integration architectures against explicit constraints. Use when making architecture decisions. Trigger with "compare Salesforce architectures".' argument-hint: "[use-case] [constraints]" allowed-tools: Read, Glob, Grep, WebFetch, Write, Edit version: 1.8.0 author: Jeremy Longshore jeremy@intentsolutions.io license: MIT tags: [saas, salesforce, architecture, decision-record, integration-patterns] model: inherit effort: high compatibility: Designed for Claude Code; new vendors, data movement, trust boundaries, and production architecture require enterprise approval

Salesforce Integration Architecture Variants

Overview

Produce a falsifiable architecture decision that explains why one interaction pattern fits each use case and which tradeoffs remain.

Prerequisites

• Use cases, business invariants, sources of truth, consumers, latency, volume, ordering, consistency, and recovery needs
• Org products, APIs, events, limits, identities, data classes, residency, retention, support, and existing platforms
• Security, operability, cost, skills, vendor, migration, lock-in, disaster recovery, and change-control constraints

Tool Discipline

Use Read, Glob, and Grep to inspect approved repository and evidence files, WebFetch to re-check current first-party Salesforce documentation, and Write or Edit only for secretless plans, fixtures, configuration, and redacted receipts.

Current Contract

Salesforce documents remote process, batch, data synchronization, and event integration patterns. Direct REST, composite, bulk, Pub/Sub or CDC, middleware, event relay, and replicated read models differ in coupling, consistency, capacity, and recovery.

Authentication

Model client apps, OAuth flows, principals, scopes, CRUD and field access, sharing, secret custody, rotation, revocation, and break-glass separately for every variant.

Instructions

1. Write decision drivers and non-negotiable invariants before naming a preferred technology.
2. Model direct synchronous API, managed or customer middleware, Salesforce events, scheduled bulk, replicated data, and hybrid variants.
3. For each, trace authority, data and event flow, transactions, ordering, idempotency, limits, failure isolation, reconciliation, and recovery.
4. Evaluate security, privacy, residency, audit, operability, latency, throughput, cost, skills, vendor support, and lock-in with evidence.
5. Run threat, failure, capacity, data-correctness, and migration exercises against the leading variants.
6. Prototype the riskiest assumption with synthetic data in the lowest-risk authorized environment.
7. Record the decision, rejected alternatives, evidence, uncertainty, conditions that invalidate it, migration stages, and review date.

Approval Boundaries

Do not select a vendor, create trust, replicate data, establish new system authority, or start production implementation without architecture and owners.

Output

Return the driver matrix, diagrams, variant scores with evidence, prototype result, decision and dissent, risks, migration and rollback plan, and review triggers.

Error Handling

Condition	Response
All variants score the same	Refine measurable drivers and constraints instead of choosing by preference.
A variant lacks reconciliation	Mark it non-viable for mutable business data until a source-of-truth recovery path exists.
Key entitlement or capacity is unknown	Keep the decision provisional and obtain current org evidence.

Example

A redacted completion receipt might look like this:

usecase=inventory-view; chosen=replicated-read; writes=source-only; freshness=5m; reconcile=daily; invalidator=latency-under-30s

Resources

• Salesforce integration patterns
• Salesforce Pub/Sub API

Next Steps

Run the workflow first in the lowest-risk authorized org and preserve its redacted receipt. Schedule a review against the next Salesforce seasonal release and the customer change calendar.