What is Apex Development?

Apex development is the process of writing custom business logic and automation on the Salesforce platform using Apex, Salesforce’s proprietary, Java-like programming language. You use it when declarative tools like flows and validation rules can’t handle the complexity.

Examples of scenarios that require it include:

Automation triggers
Batch jobs
REST API callouts
Custom controllers

Because it’s modeled almost directly on Java, Apex is an object-oriented language. And it runs server-side on Salesforce’s multitenant infrastructure, which is why it has governor limits (e.g., for CPU time, SOQL query caps, heap size) programmed in.

And because of the governor limits situation, Salesforce Apex is strongly typed. You’re running multitenant code on shared infrastructure, so you can’t afford runtime type surprises eating up resources unpredictably. Strong typing catches errors at compile time instead of at runtime.

Synonyms

Salesforce Apex development
Salesforce backend development
Lightning Platform development
Custom Apex programming

Why Apex Development Matters for Salesforce Users

Your average sales rep logging calls and updating the pipeline has zero interaction with Apex. Same with most admins, who can already do a lot with point-and-click tools like Flows and validation rules.

The people who care about Apex are mostly Salesforce developers at mid-to-large companies with complex CRM requirements, or ISVs (independent software vendors) building products on top of the Salesforce platform.

For Salesforce devs, Apex matters specifically when a business has requirements that those declarative tools can’t handle. Things like:

Complex integrations with external systems (calling a third-party API and doing something conditional with the response)
Batch processing large volumes of records on a schedule
Custom logic that’s too convoluted for a flow to handle cleanly
Building custom UI components that need backend logic behind them

For those situations, Apex is basically the only option if you want to stay on the Salesforce platform. The alternative is either (a) accepting that the business requirement doesn’t get built, or (b) pulling logic out of Salesforce entirely and handling it in an external system (which creates its own mess of sync issues, latency, and maintenance overhead).

How Apex development compares to Salesforce Flows

The Salesforce Flow builder is its declarative automation tool. It’s a point-and-click, no-code, visual builder that can do a surprising amount: record updates, conditional logic, loops, calling external actions, sending emails, even basic API callouts now.

For most automation use cases at a normal company, a well-built Flow is enough. The practical rule most Salesforce teams use is to build in Flows until you can’t, then drop into Apex. Flows are easier to maintain, more accessible to admins, and faster to build for straightforward stuff.

Scenario	Use	Why
Update a record when a field changes	Flow	Standard trigger logic, no code needed
Send an email when a deal closes	Flow	Built-in email action in Flow
Route a lead based on conditions	Flow	Decision logic is what Flow is built for
Call an external API and handle the response	Apex	Needs full HTTP control and error handling
Process 50,000 records overnight	Apex	Batch Apex handles bulk volume, Flows can’t
Complex conditional business logic	Apex	Flow becomes unreadable at this complexity
Custom UI component with data from Salesforce	Apex	LWC frontend wired to Apex backend methods
Basic data validation on a record	Flow	Validation rules or Flow handle this natively
Automated approval process	Flow	Salesforce has native approval process tooling
Real-time logic triggered by user action in UI	Either	Flow if simple, Apex if logic is heavy

How Apex Works in the Salesforce Ecosystem

Apex is backend code that runs on Salesforce’s servers, triggered by user actions, record changes, or schedules. It sits between your data (stored in Salesforce objects) and whatever needs to happen with that data, be it logic, integrations, or automation.

Core components of Apex

There are nine core components of Salesforce Apex:

Classes

Apex Classes are reusable containers of logic that everything else is built on top of, same concept as any OOP language. Everything else is essentially built on top of them. In practice most classes fall into recognizable patterns like handlers, services, selectors, and utilities.

Triggers

Apex Triggers are event listeners that fire when a record is created, updated, or deleted. Want to create a new onboarding Task and assign it to the account owner every time someone closes a new deal? That’s a trigger.

They should contain minimal logic themselves, as the convention is to immediately hand off to a handler class.

Controllers

Apex Controllers are classes that serve as the backend for UI components. When a Lightning Web Component (LWC) needs to read or write data, it calls a controller method annotated with @AuraEnabled.

Anonymous Apex

Anonymous Apex is throwaway code you run once in the developer console for quick fixes or debugging and it doesn’t get saved to the org.

Batch Apex

Batch Apex is built for processing large volumes of records that would blow past governor limits if run all at once. It breaks the job into chunks and processes them sequentially. You implement the Database.Batchable interface for this.

Scheduled Apex

The Apex Scheduler runs any of the above on a timer by implementing the Schedulable interface. Examples include nightly jobs (“Every night at 2am, run this logic.”) and recurring syncs.

Queueable Apex

This one sits between regular synchronous Apex and Batch Apex in terms of complexity. You implement the Queueable interface on a class, which lets you push a job into an async queue and run it in the background without blocking the user.

Apex REST/SOAP web services

These let you expose Apex as an API endpoint so external systems can call into Salesforce. Annotating with @RestResource is for REST web services, for JSON-based integrations. @webservice is for SOAP web services, which are for XML-based integrations.

Test classes

A test class verifies that your Apex classes and triggers work like they’re supposed to. They run in isolation and don’t count against your code limit. Salesforce actually requires 75% code coverage by tests before you can deploy anything to production.

Event fires

Governor limits reset

System validates record and field-level security

Old record values loaded into trigger context

Before triggers fire (record not yet saved)

System saves record to database

After triggers fire (record now has an ID)

Apex executes handler/service class logic

Transaction commits or rolls back entirely

Apex’s relationship with Salesforce data

Salesforce stores all data in objects. Standard ones like Account, Contact, and Opportunity come out of the box, and admins can create custom ones. In Apex, these map directly to typed classes (e.g., an Account class), so you interact with records like objects in code. Creating, reading, updating, and deleting records is native Apex syntax.

You also have SOQL (Salesforce Object Query Language), which is how you query that data from within Apex. It’s basically SQL but built specifically for Salesforce’s data model. You write it inline directly in your Apex code.

On top of that, Apex powers the backend for LWC components via @AuraEnabled methods, can call Salesforce’s own internal APIs, fire platform events for event-driven architecture, and interact with Salesforce’s metadata. And it integrates with things like Salesforce Connect for external data sources and Einstein for AI features.

The Salesforce Apex Development Process

Now, let’s walk through the development process step by step, so you know exactly how it works and the nuances that come with the Apex programming language.

1. Requirement gathering

Start by gathering business requirements in plain English (do this before touching any tooling). “When a deal closes, we need to automatically create an invoice in our billing system and assign an onboarding task to the CSM.” That’s the raw requirement.

Then ask: Can a Flow handle this? Run through a quick mental checklist – does it involve record updates, basic conditionals, sending emails, simple API callouts? If “yes” to all of it and the logic isn’t deeply nested or high-volume, Flow probably suffices

If it is, then you’re in Apex territory.

2. System design

The core decisions revolve around trigger architecture, class architecture, and governor limit planning:

One trigger per object, always. Multiple triggers on the same object create an unpredictable execution order. That trigger does nothing except hand off to a handler class immediately.
Class architecture is about separation of concerns. Handlers, services, selectors, and utilities each own one responsibility and should not bleed into each other.
Governor limits require you to think about volume upfront. If thousands of records could hit a trigger at once, you need to write your logic so it processes collections of records rather than one at a time (this is called bulkification).

Limit	Synchronous	Asynchronous
SOQL queries	100	200
DML statements	150	150
Records retrieved via SOQL	50,000	50,000
Records processed via DML	10,000	10,000
CPU time	10,000ms	10,000ms
Heap size	6MB	12MB
Callouts (HTTP / API)	100	100
Callout timeout	120,000ms	120,000ms

3. Development

Classes are written like any OOP language. You declare the class, define properties, and write methods. Triggers have their own syntax that specifies which object and which events they fire on. In practice you’re rarely writing either from scratch. You’re mostly following established patterns (one trigger, one handler class) that the Salesforce dev community has standardized.

As for development, you have two main options:

Developer Console is the browser-based IDE built into every Salesforce org. There’s no setup required and it’s always available, so it’s good for quick edits, running Anonymous Apex, and basic debugging.
VS Code with Salesforce Extensions is the professional standard. You write code locally, connect to your org via the Salesforce CLI, and push/pull metadata between your local environment and the org. It gives you proper syntax highlighting, IntelliSense, a terminal, and crucially, Git integration so your code is version-controlled.

The Apex development flow

1. Write

Write code in VS Code or Developer Console.

2. Test (Sandbox)

Safely test outside the main production environment.

3. Deploy

Implement code via Change Sets, Salesforce CLI, or a CI/CD pipeline.

4. Testing

Apex classes annotated with @isTest exist purely to verify your code works. You write methods that set up test data, call your Apex logic, and assert the output is what you expect using System.assert() statements.

Good test classes cover three scenarios: normal expected data, edge cases (like empty lists and null values), and bulk data (typically 200 records, which is the maximum trigger batch size).

And remember: 75% of your Apex code lines must be executed by your test methods before Salesforce will allow a deployment.

Writing Apex test classes.
Achieving the required 75% code coverage for deployment.
Ensuring logic behaves correctly across data scenarios.

5. Deployment

The two main deployment paths are Change Sets and Salesforce DX.

Change Sets are the older, point-and-click approach. You manually add components to a change set in your sandbox and deploy it to production through the browser.
Salesforce DX (SFDX) is the modern approach built around the Salesforce CLI. Your code lives in a local project with a proper file structure, tracked in Git, and deployed via CLI commands.

The former is simple but has no version control or automation. The latter enables CI/CD, which removes manual steps entirely.

6. Maintenance and optimization

Salesforce Apex development requires you to keep an eye on two things: Apex jobs and governor limit consumption.

The Apex Jobs page in Salesforce shows the status of Batch, Scheduled, and Queueable jobs, including failures. The Developer Console and debug logs let you inspect exactly what happened during an execution, how many queries were used, CPU time consumed, and where errors occurred.

Then, as your business processes evolve, the main risks are trigger logic becoming stale when new fields or objects get added, SOQL queries breaking when data volumes grow beyond what they were designed for, and integrations failing when external APIs change. These are things you need to stay on top of.

Pro tip: The improving capabilities of Salesforce are closing a ton of gaps declaratively. It’s worth double-checking whether you can retire code that Flows can now handle natively.

Key Features of Apex Development

To recap, the most important aspects of Salesforce Apex development are:

Strongly typed and object-oriented
Mandatory testing with 75% code coverage
Hard caps on queries, DML, CPU time, heap, and callouts per transaction
Tight platform integration via SOQL, triggers, and @AuraEnabled controller methods
Async execution patterns to handle work that’s too heavy for a synchronous transaction
Declarative-first philosophy (Apex is there when Flows hit their ceiling, not the starting point)

The reason for this architecture comes down to multi-tenancy. Your Apex runs alongside every other Salesforce customer’s code on the same instance, which is exactly why runaway processes get hard-stopped rather than just slowing things down.

Common Use Cases for Apex Development

Custom business logic

When standard Flows can’t handle the complexity, Apex classes and triggers contain the logic that runs automatically on record events or user actions. For example, when an Opportunity closes, Apex could calculate a tiered commission, update a custom object, and fire a callout to an external system, all in one transaction.

Automated data processing

Apex validates data before it gets written to the database using “before” triggers. This lets Salesforce enforce rules too complex for standard validation, like making sure a contract value doesn’t exceed a customer’s pre-approved credit limit by querying a related financial object.

It also restructures or reformats data as it moves between objects or systems, typically in trigger handlers or service classes. For example, normalizing phone number formats across incoming lead records before they get saved.

And of course, Batch Apex processes large volumes of records in chunks – such as recalculating customer health scores across 200,000 customer accounts every night – and resetting governor limits between each chunk.

Third-party system integrations

Apex makes HTTP callouts to external APIs and handles the response with full control over headers, error handling, and retry logic. For example, pushing a closed Opportunity to NetSuite as a new invoice the moment a deal is marked Closed Won.

Custom user interfaces

Apex Controllers expose @AuraEnabled methods that LWC components call to read or write Salesforce data. So you could build a custom quoting tool LWC that pulls live pricing data via an Apex method and saves the configured quote back to Salesforce.

Scheduled jobs and batch processing

Classes implementing Schedulable run on a defined timer (usually triggering a Batch Apex job to do the heavy lifting). Your sales team might do this to run a batch job every Sunday night to archive stalled opportunities with no activity for more than 90 days.

Apex vs. Declarative Salesforce Development

It’s Salesforce development best practice to default to the platforms’ standard configuration tools (which are getting more comprehensive with every release). Use Apex when you’ve hit a ceiling, either because the logic is too complex or high-volume for Flows, or because you need features that declarative tools simply don’t support, like full API control or custom UI backends.

Advantages of Apex:

Handles logic too complex for Flows
Full control over API callouts and error handling
Designed for bulk data processing at scale
Enables custom UI backends via LWC
Proper error handling with try/catch

Drawbacks of Apex:

Requires a developer to write and maintain it
Harder to debug than declarative tools
More expensive to maintain as business requirements change
Adds technical debt if overused where Flows would suffice
Must meet 75% test coverage before deployment

When to use Apex:

Logic requires querying multiple objects conditionally
Processing thousands of records in bulk
Complex external API integration with custom error handling
Custom UI components need a backend data layer
Business logic is too convoluted to maintain cleanly in a Flow

Benefits of Apex Development

The biggest advantage of Apex development is that it offers a solution where Flows doesn’t cut it. Without the custom dev side, the Salesforce platform would hit a ceiling that most large, complex organizations couldn’t live with. Apex is what makes Salesforce extensible.

The top 10 benefits of Apex for modern enterprises are:

Bridges the gap between out-of-the-box functionality and real enterprise complexity
Lets businesses bend the platform to fit their processes rather than the other way around
Processes massive record volumes without manual intervention
Keeps complex business logic inside Salesforce rather than leaking it to external systems
Gives devs precise control over how data moves between Salesforce and third-party platforms
Surfaces real-time data inside fully custom interfaces without leaving the platform
Runs heavy workloads silently in the background without touching the UX
Enforces type safety so bugs surface during development rather than in live environments
Makes deployments auditable and repeatable through mandatory coverage requirements
Scales with the organization – the same architecture handles ten records or ten million

Best Practices for Apex Development

Most orgs get into trouble not because developers don’t know Apex, but because they write code that works fine at low volume then breaks the moment data scales up. The other killer is organizational; no standards, multiple devs doing the same thing differently, logic scattered everywhere with no clear ownership.

These five practices exist specifically to prevent that:

1. Bulkify everything from day one.

Triggers fire in batches of up to 200 records, so every method needs to accept and process collections. The practical rule: no SOQL queries inside for loops, no DML inside for loops. Query before the loop, store results in a Map, and reference the map inside the loop. DML goes after the loop on a collected List.

2. One trigger per object, logic in handler classes.

Multiple triggers on the same object fire in unpredictable order, which is why one trigger should contain a single method call and nothing else. All logic belongs in a dedicated handler class. This is what makes code testable, readable, and possible to maintain.

3. Write test classes that actually test things.

75% coverage is the floor, but that misses the point. Weak tests pass deployment and fail silently in production. So every test method should have System.assert() statements verifying the actual output. Cover happy path, null/empty inputs, and bulk scenarios with 200 records.

4. Use selector classes for all SOQL.

Never write SOQL inline scattered across triggers and service classes. Instead, centralize all your queries in dedicated selector classes. That way, when query logic needs to change (e.g., a new field or filter condition), you change it in one place instead of hunting across the codebase.

5. Handle errors explicitly.

Wrap callouts and complex operations in try/catch blocks. Log failures to a custom object or use Salesforce’s Platform Events to surface errors without swallowing them silently. An unhandled exception rolls back the entire transaction, which is sometimes correct but should always be a deliberate choice rather than an accident.

The Future of Apex Development

The main development in Salesforce Apex as of now is that it’s becoming the backbone of Agentforce. According to Salesforce’s own developer blog from their TDX 2025 highlights, Apex REST classes can now be used to build custom Agentforce agent actions directly. In other words, Apex is being wired into AI tools.

And because of that, the value of an Apex developer is shifting from writing code to designing systems. Salesforce itself published a piece in March 2026 arguing that AI tools have effectively commoditized Apex implementation.What that exposes is that the real developer value was always in systems design: understanding what to build, why, and how it fits the broader org architecture. Fast coders are being outpaced by AI; architectural thinkers aren’t.