The developer surface

This page is the map. It lays out everything you can build on the platform, grouped the way this guide is organized, so you can see the whole surface at once and jump to the part you need. Each area links to its reference section as that section comes online.

Everything here is metadata you author and deploy, or an API you call. Nothing here is a feature you toggle in a fixed product — it is all shape you define, interpreted by the engine described in How the platform works.

The data model

The foundation: what your org stores and the rules its data obeys.

• Objects and fields — objects are business entities (tables); fields are typed attributes (columns). Every object is born usable, with a tab, a default list view, a default record type, a record page, and a set of standard system fields, before you customize anything.
• Field types — the bounded, composable set of data types a field may take, each with its own storage, validation, and formatting.
• Record types — variants of an object that show or hide fields and drive which layout renders.
• Relationships — reference fields that connect objects, with cascade and restrict behavior.
• The describe layer — a read-only, queryable reflection of the org’s own shape: every object, field, permission set, and installed package, askable through the same query surface as data.

Logic

Computation and constraints, all running in one predictable save order.

• Formula fields — read-only fields computed from other fields on the same record.
• Roll-up summary fields — aggregates of a child field onto its parent.
• Overridable values — a computed value composed with an optional stored override.
• Validation rules — save-time predicates that accept or reject a write.
• Record-triggered automation — effectful “when X, do Y” logic, one pass, no re-entrancy.
• Calc functions — pure, version-pinned, typed units of registered code for anything a formula cannot express.
• Save order of execution — the fixed sequence every write flows through. The contract the rest of logic is defined against.

The user interface

All of it is metadata, delivered by packages, rendered by the engine. None of it is compiled into the platform.

• Apps, tabs, and navigation — an app is a named bundle of tabs; a tab opens a page. Navigation chrome is provided by the shell package.
• Page templates and pages — a template declares named regions; a page places components into them. Record pages also render the object’s page layout.
• Page layouts and list views — which fields and sections appear on a record, and the saved, filtered, columned views of an object’s records.
• Components — the pixel-precise building blocks placed on pages. Every component the base library ships has its own reference page here — what it accepts and in what type, what it raises, what can be read off it, what it can contain, what can be styled on it, and a worked example — generated from the exact same declaration the in-product Component Library (Setup → Component library) reads to draw its own copy, so neither can say something the other does not. A component that arrives later in a package you install documents itself the same way, on that in-product page, inside your own organisation — where an installed set is a fact about your organisation rather than a public one.
• The shell — the header, global search, notifications, the app switcher: a capability a package claims, specified as a contract on the architecture site.
• The design system — tokens, component variants, icons, wordmark: a deployable skin that re-brands every surface without touching the components, delivered as its own metadata.

Administration — the setup surface

Setup is itself a package that masters the setup capability and exposes injection points for other packages’ setup pages. Every setup screen edits metadata the engine interprets; the enforcement engine underneath stays in the kernel. The setup surface covers object and field management, record pages and layouts, apps and tabs, permission sets and sharing, automation, validation, and the rest of an org’s configuration.

Security and access

The engine enforces access on every read and write; you author who gets what.

• Permission sets and groups — additive grants of object, field, app, and tab access. There are no profiles; access is composed from sets.
• Field-level security — per-field readable/editable control, enforced in the query plan.
• Roles and sharing — record-level access expressed as ownership, org-wide defaults, hierarchy, and sharing rules, enforced as row-level predicates.
• Identity and authentication — the principal/credential/session model, SSO, and machine identity.

Deploy and packaging

How metadata moves between orgs and travels as a unit.

• Metadata deploy — the canonical component model and the diff-validate-apply pipeline that moves it.
• Packaging — building a versioned distribution, declaring its namespace, edit, visibility, and upgrade behavior, and — the heart of the model — claiming a platform capability so a shell, a setup app, or a whole app class can be installed.
• Environments — the axes along which orgs differ (production, sandbox, scratch), what a fresh environment starts as, and how UI packages populate it.
• The marketplace — how packages are distributed, reviewed, entitled, and installed.

APIs

For headless builds and integrations, the platform is fully reachable over its APIs:

• Data API — record CRUD, query, and describe.
• Metadata API — deploy and retrieve metadata.
• Tooling API — fine-grained, per-component metadata operations for developer tooling.
• Event API — a modern publish/subscribe stream with durable replay.

The family taxonomy is specified on the architecture site; detailed per-endpoint reference lives in this guide as it is authored.

Platform services

Capabilities every org gets from the engine, usable from any app you build:

• Search — indexing and access-aware querying across objects.
• Files — files modeled as records over blob storage, under the standard access planes.
• Background work — durable jobs, scheduling, and run-as identity.
• Notifications — typed, per-recipient notifications rendered on the enforced read path.
• Reports and dashboards — saved queries and their compositions, run at the viewer’s access.
• Localization — translation, currency, and time-zone handling.
• Observability — application logging, its developer API, retention, and the standard logging app.
• Integrations — the inbound generated API, outbound callouts, and virtual objects.
• The AI platform — assistant grounding, actions, and guardrails over the org’s metadata and data.

---

Sections fill in as content is ported and rewritten for the current model. For the settled architecture behind any of this — the engine’s services, the boot order, the instance topology — the architecture site is the reference.