Apex

Apex is Salesforce's proprietary, object-oriented programming language, with a syntax similar to Java, that runs on Salesforce's servers (not in the user's browser). It is used to add custom business logic when declarative tools such as Flow are no longer enough: complex validations, integrations, batch processes and services that expose data.

Unlike a general-purpose language, Apex is tightly coupled to the platform: it has direct access to the database through SOQL and DML operations (insert, update, delete) on Salesforce objects, and it runs in a multitenant environment shared by thousands of customers. That is why Salesforce enforces strict resource limits (the governor limits): how many queries, how many records and how much CPU each transaction can consume. Writing and maintaining Apex is one of the core tasks of the Salesforce developer role.

Why Apex exists and when it is used

Salesforce offers two paths for customizing an org: the declarative one (configuring with clicks, without writing code) and the programmatic one (writing code). Most simple automations are handled with declarative tools such as Flow. Apex comes in when the requirement goes beyond what those tools can express: heavily branched conditional logic, calls to external systems, processing large volumes of records in the background or services that other applications consume.

A typical case at an Argentine company: a distributor that wants to automatically recalculate the priority of each opportunity based on the deal amount, the age of the account and the outstanding collections balance pulled from its ERP. That combination of rules and the call to the external system is programmed in Apex, which runs on the server side and writes the result to the record.

How it runs: triggers, classes and context

Apex code takes two main forms. Triggers are pieces of code that fire automatically when a record is created, updated or deleted (for example, recalculating a total every time an invoice is saved). Classes group reusable methods that are invoked from triggers, from buttons, from Flow or from an endpoint exposed as an API.

A cultural rule of Apex is that code must be bulkified: designed to process many records at once, not one at a time. If a trigger queries the database once for each record in a batch of 200, it runs into the governor limits and the transaction fails. The correct pattern is to query once, outside the loop, and operate on the entire collection.

Governor limits: the constraint that defines the style

Because Apex runs in a multitenant environment (the infrastructure is shared by all Salesforce customers), no code can hog resources and affect its neighbors. Salesforce enforces this with per-transaction limits that are worth keeping in mind:

• Up to 100 SOQL queries per synchronous transaction.
• Up to 150 DML operations (insert/update/delete) per transaction.
• 50,000 records retrievable per transaction.
• 10 seconds of CPU time in synchronous transactions.
• Mandatory 75% test coverage to be able to deploy to production.

That last point is distinctive: Salesforce won't let you push code to production if unit tests don't cover at least three quarters of the code. It is a quality guarantee that is rare on other platforms.

Apex vs. other options on the platform

The recurring business question is when it makes sense to code and when to configure. This comparison sums up the criteria:

The established best practice is declarative first, Apex when needed: solve everything you can with Flow and reserve code for what truly justifies it. This reduces technical debt and keeps the org easier to maintain.

Common mistakes

The most expensive mistake is writing Apex without bulkifying it, which works in tests with a single record but blows up against the governor limits in production when a real batch comes in. Other frequent stumbles: placing calls to external systems inside a loop, neglecting exception handling, and writing tests that only aim to hit 75% coverage instead of verifying that the logic actually works. A good test validates behavior, not just coverage.

For modern user interfaces, Apex usually works hand in hand with Lightning Web Components: the component runs in the browser and calls server-side Apex methods to read or write data. That division (business logic and data in Apex, presentation in the front end) is the platform's standard development model.