The platform is built around a small set of core components. Understanding what each component does and how they relate to each other is the foundation for all configuration work.

​

An instance is a secure, isolated environment containing an organisation's applications and data. Each organisation operates within its own instance, and data cannot be accessed outside it.

Within an instance, you can create multiple applications. An application groups together the configuration needed to support a particular business purpose - its data structures, processes, screens, navigation, and access rules.

​

Every application is made up of the following components.

Objects define how data is stored. An object is similar to a database table - it contains records representing business entities or operational data, along with attributes (fields), primary keys, and relationships to other objects. Objects are the structural foundation that all other components interact with.

Processes perform automated actions against data stored in objects. They handle tasks such as importing data, running calculations, validating records, writing results, generating outputs, and triggering notifications. Process logic is defined in an Excel workbook, which contains the formulas and rules that transform input data into output results. Processes can also be chained together to implement more complex automation.

Filters control which records are selected when data is displayed or processed. A filter operates on a single object and uses attribute values to determine which records are included - for example, records within a specific date range or belonging to a particular entity. Filters are used both in screens and within processes.

Screens present object data to end users in a tabular format, allowing them to view, filter, edit, and interact with records according to their permissions. When a new object is created, the platform automatically generates a screen, an object editor, and a screen link. These can be customised after creation to control which attributes are shown, how records are displayed, and which roles can access the screen. Multiple screens can be created for the same object to provide different views for different user roles.

Modules are logical groupings of screens that structure the application's navigation. Together, modules and screens define how users move through the application.

User roles control which applications, modules, screens, and processes a user can access, and what actions they can perform. Roles can restrict both functional access and data visibility, ensuring users only interact with the information relevant to their responsibilities.

​

All configuration is stored as metadata - definitions that describe how the application should behave. The platform reads this metadata and generates the application environment dynamically.

This means applications can be adapted by changing configuration rather than rewriting code, allowing organisations to evolve their applications as requirements change.

​

Objects store data. Screens display it. Processes automate actions against it. Filters determine which records are in scope at any given point. Modules organise screens into navigable sections. Roles determine who can see and do what.

These components are always used in combination. A process without a filter may act on more data than intended. Roles without well-defined screens and modules give users nowhere meaningful to go. Designing an application means thinking about all of these components together

​

Every configuration component has two names. The System Name is used internally and may be exposed through external interfaces such as the API. System Names are limited to 26 characters, which sometimes requires abbreviation. The Business Name is what users see in screens and navigation menus and should be descriptive and easy to understand. The two do not need to match.

Consistent Business Names across objects matter more than they might appear to - filters rely on attribute names to match records across objects, so using the same Business Name for equivalent attributes improves filter reuse.

​

A few platform characteristics are worth keeping in mind before you begin configuration, as some decisions are difficult to reverse.

Primary keys cannot be changed after an object is created, so these should be defined carefully upfront. Filters rely on attribute names to match records, so consistent naming conventions across objects will make filters more reusable and reduce maintenance overhead. Related objects displayed in editors cannot be filtered by end users, which is worth accounting for when planning screens.

Because process logic is defined in Excel workbooks, it is often worth designing those workbooks before finalising the data model. Working through the calculations first tends to reveal which attributes are needed, how records will need to be filtered, and where results will be written - which in turn informs how objects should be structured.

​

All configuration is performed within the Configuration application. For a full list of configuration screens and what each one is used for, see Configuration Application Reference.