Who this is for. Everyone. Every other page in these docs uses these words without explaining them again, so this page is the contract between them. Keep it open in a tab while a term is new; each section links to the page that covers its subject in depth.
Client
The customer account. A client owns one or more sites and has its own database, which holds the content, users and configuration of all of them. Input types belong to the client, so every one of its sites shares them; a layout can belong to the client, for all its sites, or to one site.
Site
One website of a client, with its own pages and other records, its own settings and its own theme repository. Most records belong to exactly one site.
Environment
One running copy of a site, such as production or a development copy. Each environment has its own hostnames and a folder of site files on the server, sometimes shared with another environment. It can follow one branch of the theme repository, so that pushing that branch deploys to it. Whether an environment runs in development mode, with detailed errors, no page cache and the debug panel, is set on the server by Core dna, not in the admin. See Environments.
Hostname
A domain name that reaches the platform, such as www.example.com. Each hostname belongs to exactly one environment, and that is how every request is matched to a site. A development copy on Core dna's development servers answers on a hostname such as examplecom-<developer>.au.coredna.dev, which the server reads as the site's examplecom.coredna.site hostname. See Hostname to site, prefix to abstraction.
Record
Any piece of content the platform stores: a page, a blog post, a product, a form, an FAQ question, a custom entity record. Many kinds of record keep revisions, and visitors see a record only once it is published. A template receives the record it is rendering under the record's own name, such as $page, and also as $record. See The built-in content types.
Layout
A record in the admin, under Customization › Layouts, that names a template file, lists the areas editors fill in, and says which controller may use it. A record chooses its layout, and the layout decides which template renders it. A layout with a controller, such as Show Page, is a page layout, offered when an editor creates that kind of record; a layout with none, shown as None (Component), is a component layout. See Layouts and areas.
Layout area
One named field on a layout, such as heading, body or heroImage, with an input type, and a label and help text for the editor. A template reads an area by its name. The content an editor enters is stored against the area itself, so renaming an area keeps the content but breaks every template and integration that still asks for the old name. See Area fields, groups and attributes.
Input type
What kind of field an area is. Its category is one of text, image, file, record, records, component, collection or widget; a text input type also has an editor, such as plain text, textarea, rich text, number, select, multiselect, switch, date or code. A select's options, a maximum length and a pattern the value must match belong to the input type too. Input types are listed under Customization › Input Types. See Input types.
Component
A block of content with its own component layout and areas, placed in another record's Component area (one block) or Component Collection area (a list the editor can add to and reorder). A global component is stored once and reused wherever it is placed, such as a site-wide banner; a template can also read one directly by its identifier, through _globalComponents. See Components.
Custom entity
A content type a site defines for itself in the admin, such as a store, an event or a team member, with its own layout of fields and its own records. A custom entity can be given URLs, for a listing and for each record, or kept for use inside other pages and through the API. See Custom entities.
Abstraction
Which side of the platform answers a request, decided by the start of its path: the API for /cdna-api, the backend, which is the admin, for /cdna-admin, and the frontend, the public site, for everything else. The same record can behave differently in each: an unpublished page opens in the admin and answers 404 on the frontend. See The URL surfaces of a site.
Member and backend user
Two kinds of user that the platform keeps apart. A member, listed in the admin as a Frontend user, signs in on the public site: a customer, a subscriber. A backend user, with the type Backend user, Administrator, Super admin or Developer, signs in to the admin, and is who an API credential or the MCP server acts as. A member cannot sign in to the admin. When these docs say a behaviour applies to one, it does not apply to the other. See Members and backend users.
Job
Automation defined in the admin under Customization › Orchestration: what starts it (an event on a record, a request to its web event URL, a schedule, or another job's Trigger job action), optional conditions, and the actions it runs in order, such as sending an email or calling another system. Each run is a job run, listed under Orchestration › Batch Logs. Jobs were called hooks, and job runs hook batches, before the module was renamed; the API's routes (/cdna-api/hooks/… and /cdna-api/webhook/…) and the code still use the old name. See Jobs and events.