How the Pieces Fit Together
The platform is easier to learn if you carry a model of how its parts relate. Nearly every question you will have belongs to one of five layers.
Where to find it
Architect Panel → Data:
- Datastores — the foundation everything else derives from
Architect Panel → Layout & Pages:
- Pages — the interface layer
Architect Panel → Security:
- Permissions — named permissions
- Record Access Roles — row-level access
Architect Panel → Automation:
- Journeys — process
- Tasks — scheduled work
1. Data
Datastores describe what you hold. Fields have types, validation and defaults; datastores have relationships, numbering, retention and audit settings.
This layer is the foundation in a literal sense — the four layers above it are derived from it, so a mistake here propagates and a change here is felt everywhere. It is worth more of your attention than anything else.
2. Interface
Forms, browse views, pages and dashboards. Most of this is generated from the data layer; you adjust rather than construct.
When a field is not appearing where you expect, the question is almost always a data-layer or access-layer one rather than an interface one.
3. Access
Who can see and do what. Security groups collect users; permissions are granted to groups at datastore and field level; record access roles control which rows a person can reach.
Access is grant-based: something not granted is not permitted. There is no deny list to reason about, which makes "why can this person see this?" a question with a traceable answer.
4. Automation
Journeys move records through a process. Tasks run work on a schedule. Rules react to changes.
This layer is where a system stops being a database with forms and starts being an application.
5. Operations
Logs, audit, backups, retention, monitoring, deployment. Largely automatic, and mostly noticed when something has gone wrong — which is the argument for looking at it when nothing has.
How to use the model
When something is not behaving, identify the layer before investigating:
- Wrong or missing value → data.
- Right value, not displayed → interface or access.
- Somebody cannot get in → access.
- Something did not happen → automation, then operations.
- Everything is slow → operations.
Most time lost to debugging is lost in the wrong layer.
Build in the same order
Data, then access, then interface, then automation. Building screens before the data is settled means rebuilding them; adding permissions after go-live means discovering who has been seeing what.
Worked example
A user reports a missing field on a form. Data layer: the field exists on the datastore. Access layer: their group has no field permission on it. The interface was never the problem, and the fix takes a minute once the layer is identified — where a search through page configuration could have taken an afternoon.
Recommendations
- Identify the layer before investigating.
- Build in order — data, access, interface, automation.
- Spend disproportionate effort on the data layer.
- Look at the operations layer when nothing is wrong.