Build an app
Three ways in: install a template, describe what you need to the App Builder agent, or shape every part yourself in the designer. All three end at the same place: a draft you preview, then publish as a version.
From a template
- Open Apps and scroll to the templates gallery. Anyone can browse it; an organisation admin can install.
- Choose a template and give the app a name if you want one other than the template's.
- Installing creates the app and publishes version 1, then opens it on its home page. Change anything afterwards in the designer.
| Template | What it is for |
|---|---|
| CRM | Accounts, contacts and opportunities with a pipeline board, a sales interface and roles for sales reps (own records) and editors. Account deletion is held for a maker's approval. |
| Request tracker | Requests people raise, triaged and worked by a team, with approval before costly work starts. Roles: Handler and Requester (own requests; resolution read only). |
| Asset register | Every asset the organisation owns, who has it, where it is and its maintenance history. Staff see their own assets with the purchase cost hidden. |
| Risk register | Risks rated by likelihood and consequence, their treatments and owners, with sign-off before a serious risk is accepted. |
| Incident register | Incidents from report to close: severity, response, root cause and follow-up actions, with sign-off on serious ones. Reporters see their own incidents; root cause and lessons are read only for them. |
| Onboarding tracker | New starters from offer to their first month: tasks, equipment, accounts and who is helping, with pay kept to HR. Salary is a sensitive field: the People team can write it, hiring managers and viewers never see it. |
| Approvals log | A record of decisions that need sign-off (purchases, contracts, exceptions) with who decided, when and why. The decision fields are read only for requesters. |
The CRM, request tracker and incident register also recommend plays: stale-item nudges, a due-date radar and a weekly review written up in Space.
From a prompt, with the App Builder
Build an app on the Apps home (organisation admins) opens a chat with the App Builder: the Records Manager agent with the apps tools and the Records management tools. A starter prompt is left in the composer for you to finish: what the app is for, who will use it and what they need to do.
- Brief. The agent asks what is missing: the purpose, the people, the work they do.
- Plan. It proposes the data model and the pages as a plan in the chat before it builds anything. Change what you like.
- Draft. It creates the app and its draft definition: types, fields, a first interface, roles and any write rules. A draft never changes a live app.
- Preview. It gives you a preview card with the app's name, interfaces, record types, rules and any validation problems, and a link that opens the saved draft read-only. Only makers can open a preview.
- Iterate. Ask for changes; each edit is validated against the app: every field, type, view, role and automation it names must exist.
- Publish. Publishing is approval-gated. The approval card shows what changes: types and fields, interfaces, write rules and roles. Approve it and version 1 goes live.
| Tool | What it does |
|---|---|
apps_describe | Reads an app's definition, draft and versions. |
apps_create | Creates a new app from a brief, with its types and a first interface, as a draft only. |
apps_edit_draft | Patches the draft: types, interfaces, views, roles, write rules, data sources and custom blocks. Validated, and ungated because it is a draft. |
apps_preview | Returns the preview card and link. |
apps_publish | Publishes the draft. Approval required, with the diff on the card. |
The same agent is behind Build with AI in the designer, where it starts from apps_describe so it knows the app before it changes the draft. Its tool descriptions carry the custom block contract, so it can write a block when the standard components are not enough.
In the designer
Open an app and choose Design (makers and organisation admins), or go to /apps/<name>/design. The designer edits the draft, section by section:
| Section | What you shape |
|---|---|
| Record types | Each type's fields (name, data type, format, options, sensitive flag) and, once published, its views. |
| Interface | Interfaces, pages and components, with a component palette and properties. Build and Preview modes; the preview renders the saved draft against live data. Interfaces and components. |
| Actions | The declared actions an interface offers: create, update, change owner, archive, delete and run automation, with their inputs, confirmations and audience. |
| Write policy | The write rules. Write rules and approvals. |
| Data sources | Live and synced external sources, and a synced source's consent and run history. Data sources. |
| Access | Roles, the people in them and field access. Someone with only manage access sees just this section. |
| History | Every published version, with revert. |
Validation runs as you edit and again on save and publish. Publish version stays off until every validation error is resolved; it then shows the changes between the live version and the draft (types, interfaces, rules, roles) before it publishes.
Publish, versions and rollback
- Publishing applies the types and fields to the live tables, upserts the views and roles from the draft, stores the interfaces, write rules and data sources on the new version, and moves the app's deployment to it. Versions are immutable.
- Rolling back re-applies a previous version in full, from the History section.
- Publish and rollback check your plan's record type cap for the types a version adds (new ones, or archived ones it brings back). A version that keeps or removes types is never refused for that reason.
- An app made before Apps existed, with no interfaces of its own, runs a default interface and opens on its Data view until you design one.