Salesforce
Development Services

Start with configuration. Flow, validation rules, page layouts and the standard objects cover most processes, and they are cheaper to maintain. Custom code is worth it when:

• the logic is too complex or too high-volume for Flow;
• users need an interface the standard pages can't give, such as a guided screen or a custom component;
• Salesforce must call, or be called by, another system in real time;
• you are building an app to sell on AppExchange or to reuse across orgs.

1. Tests that test something. Salesforce requires unit tests to cover at least 75% of Apex code, and all tests must pass, before deployment to production. Coverage is a minimum, not proof of quality.
2. Bulk-safe code. Code that handles a large batch of records as well as one, and stays inside Salesforce's governor limits.
3. Source control and repeatable deployment. Every change in version control, deployed through Salesforce DX or a pipeline rather than by hand.
4. Release readiness. Code retested in the sandbox preview before each of Salesforce's three major releases a year.

To review a build or plan a new one, book a discovery call.

An Agentforce agent can only do what its actions allow. Salesforce says you can turn existing workflows, prompt templates, Apex and APIs into agent actions, and reuse platform tools such as flows and Apex to build agents on top of them. That makes custom actions a development job as much as an AI one.

In practice, a Flow suits a step admins should be able to read and change, such as updating a case or creating a task. Apex suits logic that is complex, high-volume or calls another system. A prompt template suits a step that drafts text from Salesforce data, such as a reply or a summary. Each action needs clear instructions and inputs so the agent knows when to use it, permissions that limit what it can touch, and tests that cover the cases where it should refuse.

For the full build, see Agentforce implementation services.

Moving data into Salesforce is part tooling, part development. Trailhead describes Data Loader as a client application that can import up to 150 million records at a time and can run from the command line for automated loads; it uses the SOAP API by default and can be set to use the Bulk API for large volumes. Bulk API 2.0 is built for large data sets: it inserts, updates, upserts or deletes many records asynchronously, processing the job in the background.

External IDs are what make repeat loads safe. An upsert matches incoming rows to existing records using a field marked as an external ID, such as the record number from the old system, so a load can be run again without creating duplicates and related records can be linked by the old system's keys. Good migration work adds trial loads, reconciliation reports and a cutover plan on top.

Moving from another CRM? See Salesforce migration services.

Changes made by hand in production are hard to track and harder to roll back. Salesforce's DevOps Center, now called Lifecycle Center, gives teams one place to manage changes and releases: work items track each change, source control is the record of what changed, and release managers promote changes through a pipeline from the Lifecycle Center interface or the Salesforce CLI.

Salesforce CLI controls the application life cycle from the command line: creating development and test environments, syncing source between orgs and version control, and running tests. Scratch orgs are short-term, configurable Salesforce environments, with a maximum 30-day lifespan, built from a shared configuration file so every developer starts from the same setup. Sandboxes hold longer-lived integration, user acceptance and staging work before a release reaches production.

Ongoing release work after launch is covered by Salesforce managed services.

1. Named developers. Ask who will write the code, and verify their certifications on Trailhead.
2. Sample code with tests. Look for meaningful unit tests, bulk-safe code and a trigger framework, not just 75% coverage.
3. How they deploy. Source control and Salesforce DX or a pipeline, rather than changes made by hand in production.
4. Who owns the design. An architect who decides between configuration and code before the build starts.
5. After release. Who fixes defects, how the code is documented and how it is retested before each Salesforce release.

Our guide to choosing a Salesforce development company covers the questions to ask and the red flags in more detail.