Architecture questions that keep coming up
The questions below show up once a Salesforce build gets big enough to hurt, usually while you are trying to scale it or deploy it cleanly. They read like certification study scenarios because that is where most of them start. Then they turn up on a real program.
1. Automating environment setup: SSO and DKIM
Try to automate sandbox refreshes or scratch org provisioning through a CI/CD pipeline and you hit external dependencies. Single Sign-On (SSO) and DomainKeys Identified Mail (DKIM) stop pipelines over and over.
SSO configuration automation
SSO leans on an external Identity Provider (IdP) and on trading metadata with it: SAML assertions, certificates, endpoints. The Salesforce side, the Service Provider configuration, scripts fine with SFDX tooling (sfdx force:mdapi:deploy against metadata XML files, or the Metadata API directly). The IdP side usually does not. Updating Relying Party Trusts tends to mean manual clicks or a proprietary IdP-specific API.
If you want a refresh to finish unattended, the workarounds are thin. Turn SSO off for the automated run and fall back to internal users. Or wire the IdP's own API into the provisioning pipeline, assuming it exposes something worth calling.
DKIM setup automation
DKIM means generating a key pair and putting CNAMEs into DNS. Salesforce hands you a default domain, but sending from a verified custom domain puts DNS management on you, and DNS sits outside the platform entirely. Automating it means calling a DNS provider's API, AWS Route 53 or Cloudflare say, from the same toolchain that builds the org.
Skip verification and Salesforce falls back to its default domains. Those can trip spam filters and carry none of your branding. Whether that matters in a temporary environment is a risk call, and that call decides how far the automation can actually go.
2. Data residency and international organizations
Consolidating data from an entity that has to keep its records in country, say a Chinese entity feeding a global rollup, runs straight into Salesforce's multi-instance architecture.
Salesforce Public Cloud China is a distinct environment built to comply with local regulation, data stored locally included, and it is functionally separate from the standard global instances. So the consolidation has to happen somewhere else. The usual pattern is an external reporting layer: a data warehouse, a dedicated analytics platform, or even another Salesforce org acting as a hub, pulling from the China instance and the international instances over REST or SOAP.
Whatever you build, cross-border transfer still has to satisfy the rules that apply, GDPR and PIPL among them. Pointing a China instance at a global instance for large-scale real-time reporting is architecturally messy, and the mess is regulatory separation rather than anything technical.
3. Managing API limit concerns
There is no secret sauce here. API governance comes down to picking the integration pattern that fits the use case, and the patterns are old and well documented.
Eventing with Platform Events or Change Data Capture (CDC) decouples the systems. Consumers subscribe asynchronously instead of polling you to death, which takes load off synchronous callouts. For bulk work and large migrations, asynchronous Apex (Database.executeBatch or Queueable Apex) keeps the operation inside a scheduled window and inside the governor limits of its own execution context. And for the errors you cannot design away, client-side throttling plus a retry queue, custom-built or handled by middleware, absorbs the transient limit failures.
4. Where Salesforce Connect earns its keep
Salesforce Connect, over OData or a custom adapter, hides the plumbing of direct API interactions. Developers reasonably ask what that buys them over an Apex callout they write and control themselves.
You are right that underneath, Connect is issuing API calls to the external data source. What you get back is the rest of the platform. External data renders on standard and custom Lightning pages through the normal component framework, with no Apex written to fetch and present it. External objects support validation rules, lookup relationships, search indexing, and sometimes security enforcement, depending on the adapter and what the source can do. You query a standard Salesforce object (ExternalObject__c) with SOQL rather than hand-rolling HttpRequest/HttpResponse, JSON parsing, error handling, and token refresh logic.
When the requirement is putting external data in front of users inside the Salesforce UI, Connect deletes a lot of code you would otherwise own forever.
5. Handling offline data conflicts
Reconciling edits made offline against server-side updates committed while the client was disconnected is an old synchronization problem, and nobody has a perfect answer.
Last Write Wins is the simplest default, and it rests entirely on timestamps you trust on both the client and the server. Past that, the patterns look like this:
- Server-side arbitration. When the mobile client reconnects, do not overwrite on the spot. Trigger an asynchronous process that evaluates the conflict against business rules, so a pricing change originating from the master Price Book beats a sales rep's edit unless the rep's change is explicitly locked.
- Field-level conflict tracking. For fields that matter, have the sync framework track versions per field as well as per record. If the rep changed Field A and the server changed Field B, merge them.
- Make a human decide. For high-stakes data like pricing, flag the record as conflicted on reconnect. Take the server update, queue the offline change, and make a person (an administrator, or the rep at next login) pick which version persists.
The Salesforce Mobile SDK and its equivalents give you a local data store and a sync framework. The resolution policy is still business logic, and you write it yourself in Apex triggers, asynchronous handlers, or the synchronization service.
Leave a Comment