Your Apex is about to change behaviour. Salesforce development that survives the platform, not just the sprint

API 67.0, shipped in Summer '26, makes Apex database operations run in user mode by default. SOQL, SOSL, DML and Database methods now enforce the running user's sharing rules, field-level security and object permissions, and classes with no sharing declaration default to with sharing instead of without sharing. Existing classes keep their old behaviour until they are recompiled at 67.0 or later. That is the trap: the break does not arrive on release day, it arrives months later when somebody edits an unrelated line and the class recompiles. Any Apex that quietly relied on system mode to read or write records the running user cannot see will start failing then.

WITH USER_MODE. The WITH SECURITY_ENFORCED clause is removed in API version 67.0 and later. WITH USER_MODE is a genuine improvement rather than a rename: it handles polymorphic fields correctly, and it returns the full set of access errors instead of stopping at the first one, which makes it far easier to work out what a user is actually missing. The migration is mechanical but it is not a blind find-and-replace, because some queries were relying on the old clause failing silently in ways the new one will not.

Platform API versions 31.0 through 40.0 are deprecated in Summer '27 and retire in Summer '28, across REST, SOAP and Bulk. After retirement those calls fail. The API Total Usage event and the legacy API usage reports in Setup will tell you what is calling which version, but they will not tell you which system is behind it, which is usually the hard part. We inventory the callers, trace each one to an owner, and sequence the upgrades so the noisy ones do not all land at once.

Almost always, and we will say so before quoting to build it. Flow, validation rules, formula fields and permission sets are upgraded by Salesforce three times a year and can be changed by an administrator. Apex is upgraded by you, forever. Code is the right answer for complex bulk logic, external integrations, transactional integrity, genuinely custom interfaces and anything with performance constraints Flow cannot meet. It is the wrong answer for most of what it gets used for, and a development partner whose only tool is code will never tell you that.

No, and the two are almost unrelated. Seventy-five percent is a deployment gate: Salesforce will not let you release without it. It measures which lines executed during a test run, not whether anything was checked. We regularly read orgs sitting near ninety percent coverage whose tests contain almost no assertions, so the suite proves the code ran without throwing rather than that it did the right thing. What we look for is assertions, negative cases, bulk cases and permission-boundary cases, and that last one matters far more now that user mode is the default.

Both. Alongside an in-house team we usually take the work that needs the most context or the most care: architecture review, the integration layer, the remediation backlog, and code review on everything before it merges. Taking over an inherited or offshore codebase starts with an independent read: what it does, what it depends on, where the risks are, and what will break first. You get that assessment as a document whether or not you continue with us.