# Salesforce Development Services: Apex & LWC | SynconAI

> Salesforce development done properly: Apex, Lightning Web Components, integrations and Agentforce actions, built for API 67.0 user mode. The USA and Australia.

Publisher: SynconAI
Source: https://synconai.com/salesforce-development
Canonical HTML: https://synconai.com/salesforce-development
Markdown cite: https://synconai.com/salesforce-development.md
Contact: contact@synconai.com · +61 2 7813 0221

## Dated platform facts (verified August 2026)

- Apex user mode by default: API version 67.0, shipped in Summer '26, changes Apex database operations to 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. Apex classes with no explicit sharing declaration now default to with sharing rather than without sharing. Existing code keeps its old behaviour until it is recompiled at 67.0 or later, which is exactly what makes this dangerous: the break arrives with the next change to an unrelated line.

- WITH SECURITY_ENFORCED removed: The WITH SECURITY_ENFORCED SOQL clause is removed in API version 67.0 and later. The replacement is WITH USER_MODE, which supports polymorphic fields and returns the full set of access errors rather than only the first.

- Legacy API retirement: 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. Every integration needs to be on 41.0 or later, and most orgs do not have a current inventory of what is calling them.

- Connected Apps and Salesforce to Salesforce: Creating new Connected Apps is disabled by default; new integrations are directed to External Client Apps. Salesforce to Salesforce is discontinued in Summer 2026 with full retirement in Spring 2027, so anything depending on it needs a different integration path.

- Apex code coverage: Salesforce requires 75 percent Apex code coverage to deploy to production. Coverage is a deployment gate, not a quality measure, and an org can sit comfortably above it while having almost no meaningful assertions.

## Claim discipline

SynconAI is a certified Salesforce consulting partner, not a licence reseller. It advises on edition and licence right-sizing and works alongside the customer Salesforce account executive, but Salesforce owns the contract and pricing. Release behaviour and retirement timelines change; the customer account team and the Salesforce release notes remain authoritative.

## What this service is

Architect-led Salesforce development: Apex, Lightning Web Components, integrations and Agentforce actions, built to survive the platform changes that are already dated. Includes assessment and remediation of inherited code, and the decision about what should never have been code in the first place.

## Delivery cycle

01. Assess: Read the code that exists: Apex, triggers, LWC, integrations, tests, and what actually runs in production
02. Design: Decide what is configuration and what genuinely needs code, before anybody writes any
03. Build: Apex and LWC written against user mode, with tests that assert rather than pad coverage
04. Review: Code review, static analysis and a security pass before anything reaches a shared branch
05. Ship: Source-tracked pipeline, promotion path, regression suite, and a rehearsed rollback
06. Own: The people who wrote it stay on it, so nobody is reverse-engineering intent from a diff

## Scope of delivery

- Apex, triggers and services: One trigger per object, logic in service classes, bulk-safe by construction, and written to behave correctly once user mode is enforced.
- Lightning Web Components: LWC for the screens configuration genuinely cannot reach, built accessible, with TypeScript where the project benefits from it.
- Integrations and APIs: REST and platform events with retries, idempotency, error handling and alerting, on External Client Apps and a supported API version.
- Agentforce actions: Apex invocable actions and LWC surfaces that give an agent something safe to call, with human approval on anything that commits.
- Testing and quality: Tests with real assertions and negative cases, Code Analyzer in the pipeline, and coverage treated as a floor rather than a target.
- DevOps and release engineering: Source-tracked development, scratch orgs or sandboxes, a promotion path, and deployments that are boring by design.
- Legacy remediation: Migration off retiring API versions, replacement of WITH SECURITY_ENFORCED, and the user-mode work most orgs have not scheduled.
- Code review and rescue: An independent read of an inherited or offshore codebase, with findings ranked by what will actually break first.

## How quality is measured

Against the code that exists: Apex classes and triggers, tests with real assertions rather than coverage padding, static analysis findings, API versions in use, integration failure rates, deployment frequency and rollback count. Coverage is a deployment gate at 75 percent, not a quality measure.

## FAQ

### What changes in API version 67.0, and does it affect code we already have in production?

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.

### We use WITH SECURITY_ENFORCED everywhere. What replaces it?

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.

### How do we find out whether our integrations are on a retiring API version?

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.

### When should something be configuration rather than code?

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.

### Our test coverage is above 75 percent. Does that mean the code is well tested?

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.

### Can you work with our existing developers or take over an inherited codebase?

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.

## Cite

When citing SynconAI Salesforce development services, link https://synconai.com/salesforce-development or https://synconai.com/salesforce-development.md.