What Is a Module?
A module is a self-contained sub-app you build once and embed as many times as you need — on any page, across any number of applications. Where a page is a full screen a visitor lands on, a module is a slice of an app you drop inside other screens: a booking widget, a settings panel, an activity feed, even a navigation bar.
Think of it as one module and its many placements:
The module is the definition — the sub-app itself, edited in its own builder. There is exactly one of it.
A placement embeds that module at a spot on a page. There can be any number of placements, on any page, and each can be fed different values.
A placement renders the live module, not a frozen copy. Fix a bug or restyle the module once, and every placement reflects the change immediately.
Modules Across Applications
A module can live inside the same application that embeds it, or in a separate, standalone module application that has been published and shared. A single module can therefore be reused across many different apps, not just many pages of one app.
Note: Cross-interface modules: Embedding a module from another app uses the combined form <moduleId>$$<interfaceId> as the reference. A plain module ID is sufficient when the module lives in the same app.
Why Build a Module
Reuse a whole slice of an app. Anything larger than a single component but smaller than a full app — a checkout flow, a filter bar, a details drawer — is built once and reused.
One place to change. Fix or restyle the module, and every placement across every application picks it up. No find-and-replace across pages.
Configurable per placement. Each placement can receive different values through the inputs the module declares, so the same module adapts to where it sits.
How It Works
Building a module and using a module are two distinct jobs:
Build the module in its own dedicated builder — a full workspace with its own canvas, design and data tools, and header, separate from the app that will embed it.
Embed the module by placing a Module block on a page, choosing which module to show, feeding it input values, and reacting to the output it publishes back.
Input / Output / Event contract
Values flow in and out across the embedding boundary:
| Direction | Mechanism | Usage |
| Parent → Module | Inputs | The placement passes values down into the module, keyed by input name. Inside the module, blocks read them as {{ pageInputs['inputKey'] }}. |
| Module → Parent | Output | The module publishes an output record. The parent reads it via {{ moduleBlockId['output']['outputKey'] }}. The Module block fires onOutputChange whenever the output updates. |
| Parent → Module | Inbound events | The parent calls emitInboundEvent on the Module block to push an event into the module with an optional payload. |
Module vs. Template Component
| Aspect | Module | Template Component |
| What it contains | A full sub-app — its own canvas, pages, data sources, and logic | A single reusable component with a constrained configuration surface |
| Best for | Page-sized slices: checkout flows, filter panels, activity feeds, nav bars | Component-sized pieces: metric cards, reusable headers, product tiles |
| Sharing across apps | Yes — as a published standalone module | Yes — via the template component library |
| I/O contract | Inputs, output record, outbound/inbound events | Props (inputs), output, outbound/inbound events, slots, child overrides |
Module State Behavior
By default, when a placement is hidden and later shown again, the module inside starts fresh — anything the visitor had done in it is gone. Turning on Remember state when hidden on the placement keeps its state alive across hide and show.
Note: rememberStateWhenHidden defaults to false. The reset is the behavior you get unless you opt in.
Version Preview Behavior
Warning: When you preview an older saved version of an app, a placement that embeds a module from a different application does not show that module as it was back then — it shows the module's currently-deployed version instead. The old snapshot only captured the app's own screens, never the foreign module, so its current deployed state is used to avoid an empty slot.
Frequently Asked Questions
What's the difference between a module and a page?
A page is a full screen a visitor navigates to directly. A module is a sub-app embedded inside a page — it has no URL of its own and is always hosted by a parent page. Use modules for reusable UI slices (widgets, panels, nav bars); use pages for top-level screens.
Can I use a module in a different application?
Yes. Publish the module as a standalone module application, then embed it from other apps using the cross-interface module form: moduleId$$interfaceId. Once published, any app in the workspace can reference it.
Does hiding a module's placement reset its state?
By default, yes — hiding and re-showing a placement starts the module fresh. Turn on Remember state when hidden on the placement to preserve state across hide/show cycles.
When I update a module, do all placements update automatically?
Yes. Every placement is a live view of the module — there is no frozen copy. A change to the module (new block, restyle, logic update) lands on every placement immediately after you save and publish the module.
Pages in This Section
Building a Module — where modules live, how to create one, the module builder workspace
Packages & Modules Screen — creating and managing modules and packages from the Applications manager
Custom Navigation Module — replacing the built-in navigation with a custom module
Related Pages
Template Components Overview — reuse at the component level
Slots Overview — the slot model shared by modules and template components