For users testing modularity v2 in Ninox 3.17 beta on Private Cloud

1. Core concepts

Domain modeling

Designing tables, fields, and scripts to match real-world entities in a single business domain. A clear domain model keeps modules easy to read and extend.

Loose coupling

A design rule: expose the minimum set of fields so modules depend only on the interface, not on each other's internals. The fewer fields you expose, the easier it is to update, reuse, and replace a module.

Module

A self-contained Ninox database that exposes selected tables, pages, fields, and formulas through a module interface. Other databases connect to the module only through this interface, allowing the module to be reused, updated, or replaced without exposing its internal setup.

Module interface

The schema-based contract between a source database and one or more target databases. The interface defines all exposed tables, pages, fields, and formulas, along with their public names, internal names, and record and field permissions.

Interface ID

The unique, human-readable identifier for an interface. It is the API-level identifier for the contract. Changing the interface ID creates a new interface; existing target database connections remain tied to the old ID and stop syncing until they connect to the new one.

Separation of concerns

The practice of giving each module a single, well-defined responsibility and hiding everything else. This limits complexity and helps teams work in parallel.

2. Roles

Module provider

Builds and maintains the source database, exposes tables, pages, fields, and formulas through an interface, manages record and field permissions, and versions the interface.

Module consumer

Connects a target database to a module's interface and builds solutions on top of the exposed data.

End user

Operates the finished Ninox solution; may not know it contains modules.

3. Databases and tables

Table/field name

Caption visible only to the module provider. It can be changed at any time and is never shown to target databases.

Public table/field name

Editable label visible in target databases for a table or field. Renaming changes only the label; the underlying system ID remains the same.

Field type

Field types determine whether a field can be exposed through an interface. Supported today are data fields (text, number, date + time, yes/no, choice, multiple choice, relationship) and calculated fields (formula, dynamic choice, dynamic multiple choice). Image fields are not supported. Global functions will be supported soon.

External table

A table that Ninox automatically creates in a target database for every table exposed by a source database. External tables mirror the source data and stay in sync while connected. Field mapping is applied during creation. If the connection is removed, the table remains in the target database with all data intact and behaves like a regular local table.

Target database

A database that connects to a module's interface. Ninox creates external tables in the target database for each exposed table in the source database, applies field mapping, and keeps the data in sync while the connection is active. A target database can also act as a source database for downstream modules.

Source database

The database owned by the module provider. It contains the authoritative tables, pages, fields, and formulas, and exposes selected elements through a module interface. The source database always retains write access and controls interface versions and permissions.

4. Interface actions

Expose (verb)

Make selected tables, pages, fields, or formulas available through a module interface. Each exposed element receives a public name and defined access permissions set by the module provider.

Provide (verb)

Supply live data to connected target databases through an interface. The source database owns the authoritative records and applies all updates according to the interface's permissions.

Use (verb)

Connect a target database to a module's interface and work with the exposed data and logic according to the defined permissions. Using a module means relying on the interface contract, not accessing the source database's internal tables or scripts directly.

5. Data flow and permissions

Read-only access

The default permission for an exposed table or field. Target databases can view source data but cannot modify it.

Read and write access

Allows target databases to edit source data through the interface. The source database always retains write access internally.