-
Modularity concepts
For users testing modularity v2 in Ninox 3.17 beta on Private Cloud ℹ️ Note: This article describes the conceptual model of modularity. For current implementation limits (such as unsupported field…
-
Modularity glossary
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.…
-
Modularity FAQ and quick start
For users testing modularity v2 in Ninox 3.17 beta on Private Cloud 1. Introduction Modularity lets you build a self-contained Ninox database (a module) that plugs into other databases through a…
-
Creating and editing a module interface
Create and edit a module interface to control which source data and functions are exposed for syncing to a target database To create a module interface A module interface defines which tables, fields,…
-
Connecting a module to an existing table or a new table
Connect a target database to a module from a source database to sync exposed data To connect a module – option to create new table When you connect a module for the first time,…
-
Calculated fields in modules
Share logic across modules by exposing computed fields that update automatically in target databases Ninox supports sharing calculated fields in modules.…
-
Selecting dependencies for calculated fields
Expose everything a calculation needs so it can be evaluated correctly in the target database When a module provider exposes a calculated field in a module,…
-
Selecting dependencies when calculations reference tables
Choose a meaningful display field when a formula depends on a table, not just a single field If a calculated field in a module depends on a table (rather than a single field),…
-
Image fields and calculated fields in modules
Image fields can't be shared, and they can block exposing or updating formulas that depend on them ℹ️ Note: Image fields aren't supported in modules. Because of this:…
-
Relationship fields in modules
Share links between records while keeping relationships consistent across connected modules Relationship fields can be shared in modules through interfaces.…
-
Relationship fields show IDs by default
Expose additional fields to make related records readable in target databases After a relationship field is connected, it initially appears in external tables as record IDs only in the target…
-
Selecting and mapping relationship fields
Relationship pairs are handled automatically, but display fields must be chosen explicitly When a relationship field is exposed: The reverse relationship is included automatically.…
-
Mapping fields in modules
Remap source and target fields to the same interface fields to keep connections stable as databases evolve Field mapping lets module consumers connect a target database to a module and align incoming…
-
Remapping fields in modules
Keep module connections stable when databases or interfaces change You need to remap fields when the connection between a module and a target database can no longer rely on the previous field…
-
Reconnecting a module to restore syncing
Reconnect a module to restore syncing after the source or target database was moved or deleted, and choose how to handle data conflicts If syncing stops,…
-
Removing exposed data from a module interface
Remove exposed fields or global functions by editing the module interface and deselecting the items you no longer want to expose You can remove exposed data as part of editing the module interface.…
-
Deleting a module interface
Delete a module interface if you no longer want to expose source data or functions for syncing to a target database Deleting a module interface removes access to the exposed tables, fields,…
-
Mailhook
Ninox 3.10 introduces 'Mailhook'—a centralized receive-only inbox that stores emails in a Ninox database ✅ Mailhook is available for Private Cloud. Keys features at a glance Storage:…