Salesforce Platform: Apex, Security & Releases

Salesforce Platform

Salesforce began as a CRM and became a platform: thousands of organizations run sales, service, partner portals, and custom business applications on it, with data models, automation, code, and user interfaces built inside their Salesforce org. Developers work with declarative tools (objects, fields, Flows, page layouts) and code (Apex, SOQL, Lightning Web Components), on a multitenant platform that enforces strict resource limits and releases new versions three times a year.

Engineers coming from conventional application development find Salesforce both familiar and surprising: Apex looks like Java, but every transaction runs within governor limits; security is mostly configuration, but code can bypass it if written carelessly; and deployments move metadata between orgs rather than containers between servers.

TL;DR

Data lives in standard and custom objects with fields and lookup or master-detail relationships.
Governor limits cap queries, DML statements, CPU time, and heap per transaction — code must be bulk-safe.
Access is controlled by org-wide defaults, the role hierarchy, sharing rules, permission sets, and field-level security.
Apex should run with sharing and use user-mode queries and DML to respect permissions.
Prefer Flow for declarative automation; legacy Workflow Rules and Process Builder are retired.
Integrate through REST, Bulk, and event APIs with OAuth; govern releases with sandboxes, Salesforce CLI, source control, and tests (75% Apex coverage minimum for production).

Quick Example

A bulk-safe trigger handler that creates onboarding tasks when opportunities are won, respecting the running user's permissions:

A test proving it works for 200 records at once, the size of a typical bulk update:

Core Concepts

Data Model

Design the data model deliberately; changing relationships after records and automation depend on them is expensive.

Governor Limits

Because tenants share infrastructure, every transaction has limits — for example on the number of SOQL queries, DML statements, records retrieved, CPU time, and heap size. Code that queries or writes inside loops works in testing with one record and fails in production when a data load updates 200 at once. Write bulk-safe code: collect IDs, query once, build lists, and perform one DML per object type. Use asynchronous Apex — Queueable, Batch, and Scheduled jobs — for large volumes.

Security and Sharing

Salesforce recommends granting permissions through permission sets rather than profiles. Apex runs in system context by default: declare classes with sharing, use WITH USER_MODE in SOQL and as user DML (or Security.stripInaccessible) so code respects object and field permissions. See Authorization Models.

Code and UI

Apex: classes, triggers, asynchronous jobs, callouts, and tests.
SOQL and SOSL: object queries and text search, with relationship queries instead of joins.
Lightning Web Components: standards-based web components for custom UI.
Flow: declarative automation for record changes, screens, and scheduled processes; Workflow Rules and Process Builder have reached end of support, so migrate them to Flow.

Keep one trigger per object delegating to handler classes, and avoid overlapping Flows and triggers on the same events.

Integrations

Authenticate integrations with OAuth through connected or external client apps — the JWT bearer flow suits server-to-server integrations — using dedicated integration users with minimal permissions. Respect daily API limits, use bulk and composite APIs for volume, and make integrations idempotent with external ID fields. See Enterprise Integration and Webhooks.

Release Governance

Environments: developer, partial-copy, and full-copy sandboxes, plus short-lived scratch orgs created from source.
Source-driven development: metadata in Git, deployed with the Salesforce CLI (sf) and packaged with unlocked packages where appropriate.
Tests: production deployments require at least 75% Apex code coverage, but meaningful assertions — including bulk and permission scenarios — matter more than the number.
Releases: Salesforce ships three major releases a year (Spring, Summer, Winter); preview sandboxes let you test before your production org upgrades.
Change control: review metadata changes in pull requests and limit who can change production directly.

Best Practices

Bulkify Everything

Assume every trigger and Flow will process hundreds of records at once, and test with that volume.

Enforce Permissions in Code

Use with sharing, user-mode queries and DML, and test with users who lack permissions, so code never exposes data the UI would hide.

Prefer Declarative Where It Fits

Use Flow for straightforward automation and Apex for complex logic, integrations, and performance-critical paths — but keep automation on each object coordinated.

Treat the Org as Code

Keep metadata in version control, deploy through pipelines, and avoid untracked changes in production.

Common Mistakes

Queries Inside Loops

Code That Ignores Sharing

Integration Users With System Administrator

FAQ

What is the Salesforce Platform?

Salesforce's cloud application platform for building and customizing business applications with declarative tools, Apex code, Lightning Web Components, and APIs, on top of its CRM data model and multitenant infrastructure.

What are governor limits?

Per-transaction limits on resources such as queries, DML statements, CPU time, and memory, enforced because many customers share the same infrastructure. Code must be written to handle records in bulk within those limits.

What is the difference between profiles and permission sets?

Profiles assign a baseline of permissions to each user; permission sets add permissions on top and can be combined into groups. Salesforce recommends managing permissions primarily through permission sets.

Should I use Flow or Apex?

Flow for straightforward, declarative automation that admins can maintain; Apex for complex logic, heavy processing, integrations, and cases where precise control or performance matters.

How do I deploy Salesforce changes safely?

Keep metadata in source control, develop in scratch orgs or sandboxes, deploy through CI with the Salesforce CLI, run Apex tests with meaningful assertions, and validate against preview sandboxes before seasonal releases.