Lightning Platform
Lightning Platform is Salesforce's platform-as-a-service layer, the underlying infrastructure that runs every Salesforce Cloud (Sales, Service, Marketing, Industries) plus any custom application built on top.
Definition
Lightning Platform is Salesforce's platform-as-a-service layer, the underlying infrastructure that runs every Salesforce Cloud (Sales, Service, Marketing, Industries) plus any custom application built on top. It includes the multi-tenant database, the declarative metadata layer (objects, fields, validation rules, flows), the programmatic layer (Apex, Lightning Web Components, Visualforce), the sharing and security model, the API surface (REST, SOAP, Streaming, Bulk, GraphQL), and the AppExchange ecosystem for distributing managed packages.
The platform was originally called Force.com, then rebranded to Lightning Platform when the Lightning Experience UI launched in 2015. The brand has shifted again in recent years toward "Salesforce Platform" in marketing, but Lightning Platform is still the working name across Setup, developer docs, and pricing pages. Buying a Platform license gives a user access to all the platform features without any of the prepackaged Sales or Service Cloud functionality, which is how ISVs and internal-app teams build custom apps without paying for CRM seats they will not use.
How Lightning Platform sits underneath every Salesforce product and custom app
The multi-tenant architecture
Every Salesforce org runs on shared infrastructure. The database is multi-tenant, with all customer data stored in the same physical tables and isolated by tenant identifier. This is why governor limits exist: the platform throttles per-tenant resource consumption (CPU, heap, SOQL queries, DML rows) to prevent any one customer from monopolizing the shared cluster. Apex code that exceeds limits raises a System.LimitException rather than affecting other tenants. The architecture is the reason Salesforce can ship three releases per year to thousands of orgs simultaneously.
Metadata-driven configuration
Almost everything in Salesforce is metadata, not code. Objects, fields, page layouts, flows, validation rules, profiles, permission sets, sharing rules, all stored as XML metadata that can be deployed via change sets, Metadata API, Salesforce CLI, or DX projects. Two orgs with identical metadata are functionally identical, which is the foundation for sandbox refresh, source control, and CI/CD pipelines. Custom code is a small slice of the metadata graph; most production org changes are metadata edits without an Apex line touched.
Apex versus Lightning Web Components versus Flow
Three programming surfaces sit on the platform. Apex is the server-side Java-like language that runs database operations, triggers, batch jobs, and REST callouts. Lightning Web Components is the client-side framework, built on web standards, for custom UI. Flow is the declarative automation tool that admins use without code. The three interlock; a flow can call an Apex action, an LWC can call an Apex method, and an Apex trigger can fire automation that runs a flow. Picking the right tool per task is a senior-architect skill.
The sharing and security model
Salesforce's record-level security is one of the most distinctive features of the platform. Org-wide defaults set the baseline (public read, public read/write, private). Role hierarchies grant implicit access upward. Sharing rules grant access by criteria. Manual shares, team shares, and Apex managed sharing fill in gaps. Profiles control object and field-level access. Permission sets layer on top. Together they form a 5-tier model where every field on every record has a computed access answer per user. Building this from scratch in a custom platform is a multi-year project; Salesforce ships it as a built-in.
The API surface
Six APIs cover most use cases. REST for synchronous request-response (most modern integrations). Bulk API for high-volume data loads. SOAP for legacy clients. Streaming for change data capture and platform events. Metadata API for deployment. GraphQL for selective field reads. Each API respects the same sharing model and field-level security; an integration user with limited access cannot bypass record visibility through the API. Rate limits are tenant-wide; one busy integration can throttle the others.
Lightning Experience versus the platform
Lightning Experience is the modern UI that runs on top of the Lightning Platform. They are not the same thing. Classic UI also runs on Lightning Platform; the platform has outlived the UI rebrand. Mobile App, Slack-CRM integrations, Experience Cloud sites, Salesforce Console, and DataLoader all sit on the same platform with different presentation layers. When someone says "we are migrating to Lightning," they usually mean migrating UI from Classic to Lightning Experience, not migrating off the platform itself.
Platform licenses and what they unlock
The Lightning Platform license tiers are Platform Starter, Platform Plus, and Platform (enterprise-tier). Each gives a user access to custom objects, custom Apex, the API, and 10-20 standard objects (typically Account, Contact, Custom Object access) but no Opportunity, Lead, Case, or Cloud-specific features. This is the path for orgs building custom apps that do not need CRM; you pay for the platform without the Cloud premium. The license is also what ISVs distribute their managed packages on.
Choosing whether to build on Lightning Platform versus elsewhere
Lightning Platform is not configured the way a feature is. It is the foundation every other feature runs on. The decision points below cover when to use it versus when to look elsewhere.
- Evaluate the fit
The platform is ideal for record-centric apps where users need to view, create, and update structured data with role-based access. It is poor for high-volume event streaming, real-time computation, or large-binary file workflows.
- Pick the license tier
Platform Starter for sub-10-object apps. Platform Plus when you need more custom objects and external integrations. Platform license when the app integrates closely with CRM data but you want to avoid full Sales/Service Cloud licensing.
- Set up source control and deployment
Use Salesforce DX with a Git provider. Track metadata in source, deploy via CLI or CI/CD pipeline. Skip change sets for production deploys above trivial complexity.
- Provision environments
Production org, plus full sandbox for UAT, plus partial sandbox or developer sandboxes for dev. Refresh cadence depends on data volume; Full refreshes are slow and licensed separately.
- Plan for governor limits
Every code-driven workflow needs to respect Apex CPU, SOQL row, and DML limits. Bulkify everything. Use platform events or Queueable Apex to push high-volume work async.
Starter, Plus, or Platform. Each adds custom object allowance, API access, and feature scope. Pick based on app complexity and integration depth.
Apex (server-side), LWC (client-side), Flow (declarative). Pick per task: flows for admin-managed automation, Apex for triggers and async, LWC for custom UI.
REST, SOAP, Bulk, Streaming, Metadata, GraphQL. REST for most integrations, Bulk for batch loads above 10k rows, Streaming for event-driven, GraphQL for selective field reads.
Developer (cheapest, schema only), Developer Pro (schema plus 1 GB data), Partial Copy (schema plus sample data), Full (production clone). Plan refresh cadence per tier.
- Governor limits are not optional. Code that works in dev with 10 records breaks in production with 10,000 unless bulkified.
- Platform licenses do not include Opportunity or Case access. Adding those tables to a custom app requires a Sales or Service Cloud upgrade.
- Multi-tenant means every release applies to every customer. There is no "we will skip this release" option for the platform itself.
- The sharing model recomputes on group membership changes. Large role-hierarchy changes can lock the org for minutes during the recalc; Defer Sharing Calculation is the workaround.
- API rate limits apply per org, not per user. One badly-written integration can starve the platform for everyone.
Trust & references
Straight from the source - Salesforce's reference material on Lightning Platform.
- Salesforce Platform License TypesSalesforce Help
- Execution Governors and LimitsSalesforce Developer Docs
Hands-on resources to go deeper on Lightning Platform.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does Lightning Platform represent in the Salesforce Platform?
Q2. What architecture concept is Lightning Platform an example of?
Q3. How does Salesforce's multi-tenant model affect Lightning Platform?
Discussion
Loading discussion…