Application Foundations

Every Pianola application has a recognisable structure.

There is an application shell with a name, logo, colours, navigation, login flow, and general interface behaviour. There are modules that users open from the navigation. Most modules show records, and those records can be opened through different views, organised into tabs and sections, filtered through queries, and shown in record lists with selected columns.

This common structure is part of what makes Pianola different from a fully custom application where every screen pattern has to be designed from scratch. Pianola already provides the main application patterns used in administrative software. A project still needs to decide how those patterns should be configured for the organisation, the data, and the workflows.

This part of the documentation, Application Foundations, explains how these structures work and which configuration decisions shape them in a project.

It does not describe every individual input field, button, table, or layout component. Those details are covered in the Components section. This section describes the larger structures those components sit inside: the app shell, modules, views, lists, settings, sharing rules, and dynamic behaviour.

Shared Application Structure

Some parts of a Pianola application are present before any individual module is considered.

The application needs a name, visual identity, default language, number formatting, login behaviour, error message, and security settings. These app configuration choices affect the whole interface rather than one module at a time.

The navigation structure is part of the same foundation. Module names, paths, icons, colours, dividers, submodules, and access rules define how users move through the application and which areas of work are visible to them.

Module Structure

Most Pianola applications are organised around modules.

A module usually represents one main type of record: people, projects, organisations, events, documents, applications, bookings, tasks, or another business object. Good module structure starts with the way users think about the work, not only with the database tables behind it.

Some modules are record-based. Others are dashboards that present summaries, tables, actions, reporting areas, or workflow hubs directly. Larger modules can then be divided into tabs and sections so the screen follows the work rather than becoming one long flat form.

The exact rows, columns, fields, buttons, and related-record components are component-level choices. The foundation decision is how each module should be organised so users can find the right area of work quickly.

Views and Lists

The same records can be useful in different layouts.

Some users need a mixed view where a list and the selected record are visible together. Some workflows need a focused single-record view. Others depend on a full list, a horizontal master-detail layout, or a calendar. Each module can define its default view so users start in the layout that best matches the work.

Lists are central to many Pianola workflows, but list configuration is often misunderstood because two separate decisions are involved. A query decides which records are included. A column selection decides which fields are visible for those records.

For example, a query might find all approved participants. One column selection might show check-in information, while another shows email addresses and communication preferences. The records are the same; the visible information changes. The Record Lists page explains this distinction in more detail.

Supporting Configuration

Some data in a Pianola application is not a workflow record in itself, but a controlled value used by other records.

Statuses, categories, countries, venues, departments, document types, and similar values often belong in settings and value tables. These values support fields, filters, queries, reports, and other parts of the application without necessarily becoming full modules themselves.

Some applications also need selected data to be available outside the main interface. External data sharing uses the same query and column-selection principles to define exactly which records and fields are shared.

Interface Rules

Applications also need rules for when information is visible or editable.

Conditional display can show or hide tabs, rows, columns, fields, buttons, and related-record areas based on record values, workflow state, or permissions. Read-only states keep information visible while preventing changes when data has been approved, imported, calculated, locked, or permission-controlled.

After these foundations are clear, the component catalogue can be used to understand the individual fields, layout elements, related-record displays, actions, and media components that fill the module screens.