Salesforce Platform Integration Architect

Every connection must prove who is calling. You assess how each system authenticates, then choose among OAuth, certificates and stored credentials, and decide where secrets live and how they rotate.

• How each system in the landscape authenticates
• OAuth flows for server-to-server calls
• Client certificates and mutual authentication
• Named credentials and where secrets live
• Rotating and revoking credentials
• Single identity for users across systems

You build An authentication matrix that pairs each connection with a method.

The same data flow needs different designs at different speeds and sizes. You pull out functional and non-functional requirements, classify the data, and weigh growth and regulation before choosing anything.

• Functional requirements for a data flow
• Latency, throughput and availability targets
• Data classification and sensitivity
• Regulatory and residency constraints
• Growth and seasonality
• Recording requirements so they can be tested

You build A requirements sheet for each integration, with measurable targets.

A diagram becomes a design through an inventory of systems and the pattern each link needs. You add security and performance requirements to every link, and size volume and latency so patterns can be chosen on evidence.

• From landscape diagram to interface list
• Naming the pattern each link needs
• Security requirements per interface
• Sizing volume, frequency and latency
• Identifying the system of record per data set
• Reviewing requirements with each system owner

You build An interface inventory that lists the pattern, volume and security need of each link.

Some integrations need an answer now, and others only need delivery. You work through request and reply, fire and forget, and event-driven designs with platform events, and learn what each demands of both sides.

• Synchronous request and reply
• Asynchronous fire and forget
• Platform events and change data capture
• Updating the user interface when data changes
• Callout limits and long-running calls
• Choosing between polling and events

You build Two designs for one requirement, one synchronous and one event-driven, compared.

Large data sets and rarely used data call for other patterns. You design batch synchronization, remote call-in from other systems, and virtualized access through external objects, and know when each is the wrong choice.

• Batch data synchronization design
• Delta detection and change tracking
• Remote call-in from external systems
• Data virtualization with Salesforce Connect
• Limits and latency of virtualized data
• Choosing among batch, call-in and virtualization

You build A batch synchronization design with delta detection and a virtualization alternative.

Salesforce offers several APIs, and each has strengths and limits. You compare REST, SOAP, Bulk and composite requests, and event interfaces, then match one to each requirement with its limits stated.

• REST and SOAP APIs compared
• Bulk API for large volumes
• Composite requests to cut round trips
• Event interfaces for streaming data
• API limits and how they are counted
• Matching an API to a requirement

You build An API selection table that justifies one interface per requirement.

An integration user is a standing credential, and attackers look for it. You apply connected apps, integration users with narrow permissions, IP controls and encryption in transit, and protect sensitive fields that travel.

• Connected apps and OAuth scopes for integrations
• Integration users and least-privilege permission sets
• IP restrictions and network paths
• Encryption in transit and at rest
• Protecting sensitive fields in payloads
• Auditing integration activity

You build A security design for one integration, with a least-privilege integration user.

Design decisions made here outlive the project. You build custom inbound endpoints with careful versioning, and outbound calls that handle timeouts, limits and changing partner systems.

• Custom Apex REST endpoints
• Versioning an interface without breaking callers
• Outbound callouts and external services
• Timeouts, limits and bulk-safe callouts
• Contracts and schemas with partner systems
• Testing integrations with mocks

You build A versioned inbound endpoint and an outbound call design with test mocks.

Every integration will fail at some point. You design retries, idempotency and dead-letter handling, and plan for the day a connected system changes its interface or Salesforce updates its platform.

• Classifying failures: transient, permanent and partial
• Retries, backoff and idempotency
• Dead-letter queues and manual recovery
• Circuit breakers and graceful degradation
• Surviving API version changes
• Testing failure before it happens

You build A failure-handling design with retry rules and a recovery path for each error class.

A live integration needs owners and routines. You define monitoring, escalation, recovery steps and reporting, so that a failure at three in the morning has a documented path and a named person.

• What to monitor in an integration
• Alerting and escalation paths
• Runbooks for recovery
• Reconciliation and data repair
• Reporting on integration health
• Change control for live interfaces

You build A monitoring and runbook pack for one production integration.

Take a landscape of systems and design the integration solution: requirements, patterns, APIs, security, error handling and operations. You defend each choice and state the trade-offs you accepted.

• Reading the landscape and requirements
• Choosing patterns and APIs
• Designing security and error handling
• Planning operations and monitoring
• Presenting and defending the design

You build A full integration solution design for one landscape, with its trade-offs written down.