Global function mapping allows consumers to use functions exposed by a provider through a module interface.

When a function is made public, it becomes part of the interface contract. Consumers can then map and call that function as part of their own workflows, while the provider remains responsible for the function definition.

This means that business logic can be defined once and reused across multiple databases.

How it works

A provider defines a global function and exposes it through the interface. When a consumer connects to that interface, the function becomes available as part of the imported structure.

Internally, Ninox handles the necessary translation between interface-level identifiers and local database identifiers. This allows functions to remain stable externally even if the internal schema differs.

A module interface can expose global functions in addition to fields. When configuring public functions, you select which functions are shared and review their parameters, return type, and execution context.

Runs in

The Runs in setting defines where the public function is executed when it is called through the module connection.

• Source: the function runs in the source database (the provider).
• Target: the function runs in the target database (the consumer).

This matters because the execution context determines which data, logic, and permissions the function can use.

Runs in: Source

When a function runs in Source, it is executed inside the provider database.

Use this when the logic should stay on the provider side, for example when the function:

• needs access to provider-specific tables, scripts, or internal logic
• should use fields that are not publicly exposed
• should return only a controlled result instead of exposing raw underlying data

This is especially useful for encapsulation and data protection. A source-side function can work with sensitive or internal data in the provider database, while only returning the output that the consumer is allowed to receive.

Example:
A provider database contains employee salary details that should not be exposed directly. A public function running in Source could calculate and return only the total budget or a yes/no validation result, without exposing the salary fields themselves.

Runs in: Target

When a function runs in Target, it is executed inside the consumer database.

Use this when the logic should operate in the target context, for example when the function:

• needs access to target-side data
• should work with mapped or imported records in the consumer database
• is meant to continue processing after provider data has already been synced or made available

In this case, the function does not execute with direct access to the provider’s internal, unexposed data. It only works with what is available in the target database.

Why this is important

Choosing Source or Target is not just a technical detail — it affects:

• data visibility
• security and privacy
• which database logic is used
• how much of the provider’s internal structure is exposed

In general:

• choose Source when you want to keep logic and sensitive data on the provider side
• choose Target when the function should run as part of the consumer’s own workflow

Benefits of global function mapping

Global function mapping creates a single source of truth for logic.

Instead of maintaining the same formula or workflow rule in multiple places, teams can centralize logic in the provider and reuse it everywhere the interface is consumed.

This improves consistency and reduces maintenance effort, especially in larger modular systems.

Designing shared functions carefully

Because exposed functions are shared across databases, they should be treated as stable contracts.

Changes to function parameters or return behavior may affect all connected consumers. Shared functions should therefore be introduced and updated with the same care as exposed fields.