Salesforce Architecture
Health Cloud, Apex, governor limits, packaging, and the platform behaviour that surprises you in production.
9 pieces
The platform composes behavior at runtime out of layers you did not explicitly declare. Sharing context, permission layers, the front-end security runtime, the encryption boundary, the meaning of a status code. In each case the default is not neutrality. It is a posture you took by accident.
So the work is making the implicit explicit. Omission of a sharing keyword is itself a declaration, which is why the keyword goes on every class, especially the permissive ones, so the choice reads as deliberate to whoever finds it next. An async endpoint that returns 200 is not a business-logic problem, it is a lie in the status code, and every client pays for it.
Where validation is involved, ground it in something the platform controls rather than something you maintain. Bind variables cover filter values and cannot cover field or object names, so structure gets validated against a live schema describe: an attacker can fake a config entry, not a describe response. Better still, remove the conditions under which a secret can exist, so the finding moves from you stored a secret badly to you hold no secret.
Two failure modes recur, and neither is carelessness. The first is accumulation: the wildcarded setting from a dev environment, the credential nobody rotated, sprint-four config still shipping eight months later, each of which survived every checkpoint because it was temporary when it was added. The second is the permissive dev org, where the same code passes on your org and breaks on theirs because two security runtimes enforce different rules and you wrote to the more forgiving one instead of the intersection.
The rest is sequencing. Earn the right to touch a persistent org by proving it against a disposable one, validating by metadata type so a failure is a needle rather than a wall. Ask which layer an error came from, not which layer it names, because three permission layers fail at whichever one catches the request first. And ship before you package, because every field in a released managed package is a field subscribers can never delete. Ship when the product is ready. Package when the contract is ready.
The pieces
- Two Orgs. Same Code. One Breaks.
I stared at the console error for longer than I want to admit.
- Your Apex class has a sharing posture. You just haven't declared it.
I was reviewing a service class in a mature org. Clean code, well-tested, passing all the gates. Then someone asked: "Is this running with or without sharing?"
- Why We Source-Deployed a Production Salesforce App Before Packaging It
There is a question that comes up the moment you are about to ship a Salesforce app to a real customer org. Not a sandbox. Not a scratch org for a demo. A real production environment with real users who are going to depend on this thing every single day. The question sounds responsible. It sounds like the mature, professional path. "Should we package this before we go live?"
- Your Salesforce REST endpoint should return 202, not 200
There is a moment every API builder knows. You ship the endpoint, the integration team says it works, and three weeks later something upstream starts misbehaving in ways that do not make sense. The data is there, eventually. But a consuming client timed out waiting for it, or gave up and retried, creating duplicates. The logs show nothing technically wrong.
- The Shield Gap: PHI in Platform Events
Shield was on. The fields were encrypted. The security assessment was scheduled for next month. Everyone felt good.
- Killing Secrets in Packaged Apps
There is a specific feeling when a security review comes back with "hardcoded credentials" in the findings. Not embarrassment exactly. The slow realization that you already knew, somewhere, that the way you wired that callout was always going to end here. Temporary became permanent. And now it is a blocker.
- Dynamic SOQL Without Getting Burned
There is a particular kind of dread that sets in at two in the morning when you realize the query you shipped last week can be turned against you.
- When a Salesforce deploy fails on permissions you already granted
The deploy succeeded. The data transfer failed. The error lied to me.
- Scratch-org-first as a deploy discipline
The first time I pushed a half-shaped metadata manifest straight to a shared sandbox, I cost my team an afternoon. The org was dirty from a previous sprint, the error message made no sense, and rolling back took longer than the deploy itself. Expensive. And completely avoidable.