What's Really Changing?

Clearer Language

We're flipping how we describe relationships to better match how you think

Better setup experience

No more confusion about which table to use

Nothing breaks

All existing connections work exactly as they have been

Think of it like this:

Instead of saying 'one company has many contacts,' we now say 'many contacts belong to one company.' It's the same relationship, just described from the perspective that makes more sense to most users.

👍
Existing connections in both Classic and Next-Gen connection fields continue to function as expected with some interface updates.

New Connection Behavior in Next-Gen

When creating new connection fields in Next-Gen apps, you'll see these available connection types:

Many → One

Multiple records in the current table can connect to one record in the connected table

Many → Many

Multiple records in the current table can connect to multiple records in the connected table

One → One

Each record in the current table can connect to one record in the connected table

📝
The One --> Many option is not available in the connection type selector for new connection fields.

Existing Connection Examples, Previous to this Change

One --> Many (In Classic and Next-Gen)

Example of the One --> Many in Classic:

In this example (from Classic Knack), while on the Leads table, a connection field is created to the Contacts table, and the default selections of One and Many were kept.

What you'll see in Next-Gen:

This is now showing as Many --> One

Functionality remains exactly the same

Interface changes in Edit Connection Field:

The connection field will display as "Many → One" in the field editor
The selection called "One → Many" option appears as disabled with a "Deprecated" label in the connection type dropdown
You cannot select the deprecated One → Many option
If your use case changes, you can still change the connection type to Many → Many or One → One connection type

Why We Made This Change

The changes were made to align the interface language with how users naturally think about and set up table relationships, and how we teach users to set up connections on the "many" table.

The Problem: Confusing Language: Users kept asking: "Do I create this on the Company table or Contact table?"

The Solution: Natural Language: Now it's obvious: Many contacts belong to one company" → Create the field on the Contacts table

Real-world analogy: You naturally think "this contact works at that company," not "that company owns this contact."

By simplifying the options for new connections and encouraging users to create "Many → One" connections from the appropriate table with a dynamic visual, errors in setting up connections will be reduced, and creating relationships will be more straightforward. Users will be less likely to create connections on the wrong table or get confused about which connection type to choose.

Many --> One Connections (In Classic and Next-Gen)

In this example, a connection is created while on the Invoice Line Items table to the Invoices table, but the default One and Many settings were manually reversed to Many and One.

As a result, a single Invoice Line Item can connect to multiple Invoices, which is an outcome that typically doesn't reflect the intended workflow.

To help prevent incorrect scenarios like the above, where an Invoice Line Item might connect to multiple Invoices, the default Many → One selection and dynamic visuals help guide users to place connection fields correctly and more intuitively from the start.

Working with Connections that have a deprecated status

Do you need to change a deprecated connection type?

No, not if the current functionality works perfectly for your use case

Normal Functionality

Connection types marked as "Deprecated" in Next-Gen continue to function normally in your live app and builder, in both Classic and Next-Gen.

Not available for with new Connections

Cannot be selected as an option when creating new connections in Next-Gen.

No Re-selection

Cannot be re-selected if you change the connection type in Next-Gen

Modifying Connections

Modifying the connection type is generally rare.

More commonly, the connection field was set up on the incorrect table, or with the incorrect selections. Like in the previous example, while in the Invoice Line Items table, a connection field was added to the Invoice table, but the selections were changed to Many Invoices to One Invoice Line Item.

It may be best not to change the connection type, but, while on the Invoice Line Items table, create a new connection field to the Invoices table with the default Many —> One selection. Delete the incorrect connection field from the Invoices table afterwards.

⚠️Note that any elements, views, rules, equation & formula fields will also cease to work or be deleted if the incorrect connection field is deleted.

Before Changing Connection Types

If you're planning to change an existing connection type:

Document your current connections - Note which tables use which connections
Review data relationships - Understand how your connections are being used. The Data Model helps to visualize connections between tables.
Test changes safely - Duplicate your app and test modifications first, in the Builder and the Live App

Data Preservation During Connection Type Changes

In both Classic and Next-Gen, if your use case changes, and you change connection types for existing fields:

No data loss occurs - All previously selected connection values are preserved
Behavior changes going forward - New record selections will follow the rules of the new connection type
For example: If you change an existing Many → Many connection type to a Many → One connection type, users will only be able to select one option in new records, but existing multiple selections remain intact

Connections Best Practices and Examples

💡 Simple Rule: Ask 'What Contains What?'

The container is the "one"
The contents are the "many"

Create the connection field while on the "many" table

Invoices contain Line Items → Create the connection field to Invoices while on the Line Items table

Companies contain Contacts → Create the connection field to Company while on the Contacts table

Many → One Examples

Project Management

Tables: Tasks and Projects

Each Task belongs to one Project, and one Project can have many Tasks
While on the Tasks table, create a connection field to the Projects table

Education

Tables: Students and Schools

Each Student attends one School, and one School can have many Students
While on the Students table, create a connection field to the Schools table

E-commerce Example

Tables: Products and Categories

Each Product belongs to one Category, and one Category can contain many Products
While on the Products table, create a connection field to the Categories table

Many → Many Examples

Determine the "many" table. This is generally the table Live App users will be working with the most. After the connection is created, then while on the "many" table, you'll be able to select multiple options in the connection field dropdown.

Event Management

Tables: Events and Speakers

Each Event can have multiple Speakers, and each Speaker can present at multiple Events
Create the connection field on either table depending on your workflow (commonly on the Events table for event planning workflows, where new records are created more often)

Course Registration

Tables: Students and Courses

Each Student can enroll in multiple Courses, and each Course can have multiple Students
Create the connection field on either table depending on your primary workflow (commonly created while on the Courses table, to easily add and remove students from Courses)

Content Management

Tables: Articles and Tags

Each Article can have multiple Tags, and each Tag can be applied to multiple Articles
Create the connection field on either table depending on your workflow (commonly created while on the Articles table for content organization)

One → One Examples

User Profiles

Tables: Users and User Profiles

Each User has exactly one User Profile, and each User Profile belongs to exactly one User
Create the connection field on either table (often on User Profiles for detailed information management)

Order Processing

Tables: Orders and Shipping Information

Each Order has exactly one Shipping Information record, and each Shipping Information belongs to exactly one Order
Commonly created on the Shipping Information table

Employee Management

Tables: Employees and Employee Details

Each Employee has exactly one Employee Details record for sensitive information
Create the connection field while on the Employee Details table to limit sensitive data access