For authors and consumers working with modular databases in Ninox 3.17 beta

1. Introduction

Heads-up while you test the beta

• Some stages are under active development, so expect UI changes and occasional rough edges.
• Keep the modularity glossary open for quick definitions of terms like provider database, external table, and interface version.
• We'll update this article as each new stage ships.

Modularity lets you build a self-contained Ninox database (a module) that plugs into other workspaces through a module interface. The pay-off is isolation, reuse, and safe updates—bugs and schema tweaks stay inside their own module, and you can release new versions without breaking consumers.

This article is for partners who are testing modularity in its beta phase. We walk you from first contact through daily use and troubleshooting. If you need full definitions, keep the glossary open in a second tab.

2. Key roles and terms

• Module author: Builds the provider database, exposes tables/fields, versions the interface, and will later publish the module.
• Module consumer: Adds the module to a workspace, connects to its interface, and may extend it.
• End user: Works in the finished solution, usually unaware that modules power it behind the scenes.

3. Understanding modules and interfaces

What is a module?

A module is a self-contained Ninox database that shares only the data and logic you choose. You can reuse it in many workspaces and update it safely without exposing your internal setup. In the future, we may add ways to package or monetize modules, but those capabilities aren't available in this beta.

What is an interface?

An interface is the public contract between your provider database and any child databases that connect to it. It defines every table and field you expose, using:

• The interface name (a versioned identifier)
• Each table ID with its public name
• Each field ID with its public name
• The access rights for each field (Read or Write)

Visual guide—module anatomy

This diagram shows how the 3 parts of a module work together today:

• Provider database: Where your tables, fields, and scripts live. Anything you expose here goes out through the interface. You always retain write access.
• Module interface: The list of tables and fields you've exposed, with their internal names, the names your users see, and each item's access level.
• Child database: What your end-users install. Ninox creates external tables here that mirror your exposed data and stay in sync while connected. You decide whether end-users can write back to those tables.

4. Module lifecycle

The diagram shows the ideal end-to-end journey for a module: Design → Expose → Test → Publish → Consume / Provide → Update / Deprecate.

Below is a walkthrough of each stage, with a note on what you can do today in the beta and what's currently not available.

1. Design – available today

   Build your schema, scripts, and business logic in a normal Ninox database. Treat this as the blueprint for your future module.

2. Expose – available today (with limits)

   Open Module settings > Configure public fields and pick which tables and data fields become public. Only data fields can be exposed in the current beta; relationship, formula, image, and dynamic (multiple) choice fields aren't available in this beta.

3. Test – not available

   Automated integration tests that validate your exposed interface before sharing aren't in the beta yet. For now, create a throw-away child database and test manually.

4. Publish – not available

   Later versions may let you package the module (including its interface) and release it to a channel so any workspace can discover and add it. During the beta, sharing is limited to private workspaces or imports (direct copies).

5. Consume / Provide – available today

   • Consume: Add the module to another workspace; Ninox creates external tables that stay in sync.

   • Provide: Once a consumer connects, your provider database supplies live data (and accepts writes if you granted that permission) through the exposed interface.

6. Update (available today – with limits) and Deprecate (not available)

   Editing anything that changes the interface name automatically creates a new version, letting consumers update when they're ready. A formal deprecation flow—where you mark old versions as obsolete and guide consumers to update—hasn't shipped yet.

5. Creating, editing, and saving an interface (authors)

1. Open the provider database and switch to edit mode.
2. From the kebab menu, access the dropdown, and select Module settings.
3. Click Configure public field and expose only what consumers really need—fewer sync points mean fewer surprises.
4. Save. Ninox bumps the interface version automatically whenever you make any changes in the interface that require saving.
5. Test in a child database before you publish.

Tip: Grant Write access sparingly; once enabled, consumers can overwrite your source data.

6. Data sharing and synchronization

Supported today: Tables and simple data fields such as text, number, date/time, yes/no, choice, and multiple choice.

Planned, not yet supported: Relationship fields, formula fields, image fields, dynamic (multiple) choice fields.

Note: We're working on a more detailed article with workarounds for unsupported fields.

7. Connecting a module (consumers)

1. From workspace home, click Add module.
2. Pick a module in the gallery and click its card.
3. Name the module and confirm Add module. Ninox creates external tables that mirror the provider's data.
4. Work normally or switch to edit mode to extend the module.

Tip: You can add several modules to the same workspace; each one lives in its own database with its own interface.

8. Reconnecting or moving a module

If a provider or child database is deleted or moved, the data stays put but syncing stops. Use the Reconnect modal to restore the link: choosing Reconnect overwrites conflicting child data with provider values, while Cancel keeps child edits so you can fix them first.

9. Names and IDs—what you can safely rename

• Interface name: Single label that identifies the API. Renaming it creates a new version and breaks existing connections.
• Public table name: Consumer-facing label mapped to a hidden system ID—safe to rename any time.
• Public field name: Same deal as tables—safe to rename because the hidden ID never changes.

10. Removing fields

Note: The UI for removing fields is still under development. Once the remove-field flow is fully released, you'll see a dedicated delete icon next to each public field and won't need to uncheck fields in the modal manually.

In the meantime, follow these steps to hide a public field from your interface:

1. Switch your provider database to edit mode.
2. Open Module settings.
3. Click Edit interface on the interface page.
4. In the Configure public fields modal, select the table you want to update from the dropdown.
5. Uncheck the fields you no longer want to expose.
6. Click Save in the modal to apply your changes.
7. Click Save interface on the interface page to finalize the update.

Tip: If you remove every field from a table, that table is automatically removed from the interface—since a module can't expose an empty table.

11. Conclusion and next steps

Thanks for helping us shape modularity. Your feedback during beta is invaluable—please share what works, what doesn't, and what you'd like to see next.