Key Concepts
A handful of concepts recur throughout Anybuild, at every level from the Designer down to the running application. This page defines each one and how they relate to each other, so the rest of this guide can refer to them without re-explaining each time.
Applications
Section titled “Applications”An Application is the top-level container for everything you build - Property Manager, Internal CRM, Invoice Tracker. Every entity, module, view, workflow, and security rule belongs to exactly one application.
Every Anybuild environment comes with a System application already built in, providing a library of ready-made components - UI components in particular - that your own applications can reuse rather than rebuild from scratch. New applications are created either through the 4-step creation wizard or directly from the Designer, where you give the new application a Name, ID, and Description.
Modules
Section titled “Modules”A Module is a sub-container within an application, used purely for organisation and navigation. Modules are hierarchical - a module can contain other modules, nested to any depth - which lets a large application’s entities be grouped logically (e.g. “Sales”, “Sales → Quotes”, “Sales → Orders”) instead of sitting in one flat list.
Modules matter beyond tidiness: the application’s navigation menu is generated directly from its module structure, so how you organise modules is also how end users will navigate the finished application. Every entity belongs to exactly one module.
Entities
Section titled “Entities”An Entity is the core building block of the data model - a real or abstract thing the application needs to track (Customer, Invoice, Patient, Booking). Entities have fields, can contain components (tightly-coupled sub-entities), and can reference other entities to model relationships.
Entities are what everything else in the platform builds on: views query them, workflows act on them, UI displays them, and security rules govern access to them. See Data Model → Entities for the full reference.
Publishing
Section titled “Publishing”Changes you make in the Designer - to an entity’s fields, a component, a security rule, a field type - exist in a draft state first. They have no effect on the live application until they are explicitly published. This applies independently to entities, field types, and views: each tracks its own published/unpublished state.
This separation exists so you can make and review several related changes before any of them go live, rather than every edit taking effect immediately. An entity with unpublished changes shows a warning indicator in the Designer until it’s published. See Data Model → Entities → Publishing for the mechanics.
Record lifecycle
Section titled “Record lifecycle”Publishing governs changes to the model (the entity definition itself). Once an entity is live, individual records of that entity move through their own separate lifecycle:
Draft → Submitted → Live → History → Deleted
A record starts as a Draft when first saved, moves to Submitted when a user explicitly submits it for review or activation, and becomes Live once approved - at which point it’s the active version end users see. If it’s later edited and resubmitted, the previous Live version becomes History rather than being overwritten, preserving a full audit trail. Deleted records are soft-deleted, not removed from the database.
This lifecycle is generated automatically for every entity - it’s not something you configure, only something you should expect to see in the generated application’s UI (the Submit button, the status badge).
Versioning
Section titled “Versioning”Every time a record moves through the lifecycle above and is submitted and approved, its version number increments. The record detail view shows the current version directly (e.g. “Draft / Version 1”), and because superseded versions are kept as History rather than discarded, every record carries a complete history of how it changed over time - who changed what, and when.
How these fit together
Section titled “How these fit together”An Application contains Modules, which organise Entities. Changes to an entity’s definition go through Publishing before they reach the live application. Once live, every record created against that entity moves through the Record lifecycle, and Versioning keeps a full history of every submitted change to that record. Together, these six concepts describe both how an application is built (Application → Module → Entity → Publishing) and how it behaves once running (Record lifecycle → Versioning).