The metadata model
The single idea that makes Salesforce development coherent is that almost everything is metadata. When an admin creates a custom field, builds a flow, or designs a page layout, they are not just changing settings — they are creating metadata records that Salesforce stores and can serialise as files. As a developer you work with that same metadata directly, as text, which is what makes source control, code review, and automated deployment possible.
Metadata comes in types: ApexClass, ApexTrigger, CustomObject, CustomField, Flow, LightningComponentBundle, PermissionSet, and many more. Each component has an API name — the stable, code-facing identifier, distinct from its human label. Custom objects and fields carry the __c suffix; custom metadata relationships use __r. Learning to think in API names rather than labels is essential because code, SOQL, and metadata files all reference them.
In a project, metadata lives as files under force-app/main/default, grouped by type — classes/, triggers/, objects/, lwc/. A custom field, for instance, is an XML file inside its object's folder. Because these are plain files, two orgs can be compared by diffing their retrieved metadata, and a change can be promoted from a scratch org to integration to production by deploying the same files.
There are two flavours of the metadata API: the older Metadata API (deploy/retrieve whole components) and the newer source-tracking model used with scratch orgs, where the CLI remembers what changed. Both ultimately move the same metadata.
The practical payoff: your org's configuration is code. Treat it that way — branch, review, and deploy rather than clicking directly in production. As an exercise, retrieve a custom object and one of its fields into your project and open the XML to see how a "point-and-click" field is represented as metadata. Next we look at governor limits, the constraint that shapes every line of Apex you will write.
