Skip to content

Using Multi References

Many-to-many relations in Database Manager: understand the junction table a multi reference represents, and when it fits better than a simple reference.

Use a multi reference when records on both sides can relate to many items on the other side, such as meetings with many attendees or projects with many tags. This is the Database Manager path for many-to-many modeling, and its main value is that the junction structure is created and managed for you instead of being hand-built every time.

For many-to-many relationships
Wappler generates the linking structure for you

Know when a simple reference is not enough

Section titled “Know when a simple reference is not enough”

A normal reference handles one-to-many: one parent, many children, with each child pointing back to one parent. A multi reference is different because both sides can relate to many records. Make that distinction before modeling the schema, otherwise you end up forcing many-to-many data into the wrong structure.

Use references for one-to-many
Use sub tables for owned child collections
Use multi references when both sides can have many links

Create the multi reference from the table context

Section titled “Create the multi reference from the table context”

Just like sub tables, multi references start from a table context in Database Manager. The important shift is conceptual: you are not adding a plain field, you are defining a relationship pattern that is represented as a junction table behind the scenes and kept visible in the manager.

The generated multi reference is really a managed junction table. It stores the links between the two related tables, which is why this feature is the right solution for many-to-many data. It removes the need to hand-build the linking table, name its keys yourself, and wire the relation from scratch each time.

A junction table sits between the two main tables
The junction stores the actual links
Wappler keeps the relationship visible in Database Manager

Why this matters for queries, forms, and UI components

Section titled “Why this matters for queries, forms, and UI components”

Multi references are not only a schema feature. They matter because later queries can expose the linked records cleanly, and update flows can write those links without you manually micro-managing the junction table. This is the foundation behind practical many-to-many UI patterns such as tag pickers, attendee selectors, and other multi-select editing flows.

Query linked records more naturally
Power multi-select editing patterns
Support components like Tagify more cleanly

Continue into related workflows depending on what you want to do next: use Tagify-style UI for many-to-many selection, inspect how nested records are queried, or go back to Database Manager recipes for another schema task.

Connect many-to-many data to selection UI
Inspect how linked data appears in queries
Return to the Database Manager recipe hub