Table of Contents

Plan Your Connections: Simple Example

Danielle Kellogg Updated by Danielle Kellogg


In this article, we will walk through the process of planning your connections. We will share tips and best practices, along with answering common questions both beginners and Knack pros have about connections.

If you’re not sure whether you need to use connections, check out our guide to Connect Related Data. You will find many examples of how connections are used in Knack apps to:

  • View related data: You can create relationships between your data so that when you view information about a company, you can also view information about all of the contacts that are associated with that company as well.
  • Ensure users only have access to their own data: Limit the data that users see on a page so that they only see the data that is relevant to themselves. This way, customers only see the orders they have created once they login.
  • Run calculations and visually summarize your data: Create reports that show the total sales made in a given month and even how much each salesperson contributed to that total.

We will plan out the connections for a customer portal. You can see the finished app here: Customer Portal Demo App.


If this your first time creating an app, you'll need to know some basics about adding objects, fields, pages and views. You can start by working through the articles in our Builder Basics section. Other good resources can be found in our designing the database and building pages sections of the knowledge base.

To plan your connections, you need to understand a few things about the app you want to build:

  • What data will you be tracking?
  • What users will be accessing your app?
  • What workflows do you want to create for your users?
  • What types of reports do you wish to create?

How you set up your connections will determine what is possible in your Live App.

Note: This article is designed to be read completely, from start to finish. To get the most value, we recommend reading the whole article.


Plan Your Objects And User Roles

Before you can determine how your objects relate to each other, you first need to know what objects you’ll need. If you’re coming from an Excel or Access/SQL background, you can think of an object like a spreadsheet or a database table. Not using either of those? That’s ok, this section is helpful for all Knack users!

Objects represent common groupings of data. Each object should only represent a single type of data. User roles are common groupings of data just like objects, but they can login!

For example, in our customer portal app we will be tracking invoices and customers. Data like customer address or phone number, while it may be important to display on an invoice, does not identify the invoice itself. That data identifies the customer. So an object for invoices containing order date and customer address no longer represents a single type of data.

The power of connections is that we can keep the data separate, yet still draw on it when we need to. We can create an invoice page in our app that displays not just the invoice’s data, but the relevant data from the connected customers.

Objects vs User Roles

In many apps, you’ll need user roles to allow users to login and access the data. In Knack, user roles are used to control permissions in and access to your app.

So, should we make a customers object or user role?

The answer to this depends on your business. In a business-to-consumer (B2C) scenario, your customers are individuals. In a business-to-business (B2B) scenario, your customers are companies, each with individuals who work there. Ask yourself - what kind of data am I working with? Who needs to login?

In a B2C scenario, the customer name, address, phone number, total spend, etc are all data points that identify an individual - a single type of data. This individual needs to log in to view their orders, update their info, and more. That means we will create a user role for Customers.

In a B2B scenario, we have two types of data. We have the customer name, address, phone number, and total spend. All this data identifies a company. We also have contacts at that company. Each contact has their own identifying info - contact name, email address, phone number, job title.

In this scenario, we create an object for Customers and a user role for Contacts. Customers represent the company data - companies are not people, so they can’t log in. Contacts represent the data of the individuals who work at the Customer companies, who do need to log in.

If you’re creating an app for internal use only, where your customers would not be logging in, there’s no need for a user role. However, if you think there’s a chance you might open this app to customer access in the future as a portal, it’s easier to make a user role for your customers from the very beginning, as objects cannot be converted into user roles. You don’t have to give them login access or create passwords right away.

Check out this guide for more information on what you can do with users in your apps: Users & Access


Let’s start with planning the objects and user roles we’ll need in our Customer Portal Demo App. This app is based on a B2B business relationship, where each customer is an individual.

We want to track a few different types of data with the Customer Portal app:

  • Customers
  • Their service requests
  • Their invoices

We also consider what users will be accessing the Live App. In this case, we want:

  • Customers to be able to login to view and edit their own records, but not be able to see anyone else’s records.
  • Managers to be able to access the system to manage the service requests and invoices.
It can be helpful to write out your objects & user roles on a piece of paper with their fields listed. Draw lines between objects to represent relationships - this will help you when you start planning the connections.

In the graphic above, you can see how we’ve split up our different types of data into objects. Each object contains data representing only a single group of data - these are the fields listed under the object name.

Because we will be connecting these objects, we do not need to store data like the customer’s address field on the Services object. The address only belongs in the user roles it identifies - Customers. You can later access that customer’s address from their connected Service records. That way, you only store and manage the data in one location.

Determine What Connection Types You Need

Once you have your objects, it’s time to determine how they are related. This is done using connections between your objects.

The connection rules that apply to objects also apply to user roles. So while we will use the word object here, know that the same rules apply to user roles.

There are three types of connection relationships in Knack:

  • One-to-many: Each Contact connects to one Company, but each Company is connected to only many Contacts.
  • Many-to-many: Each Student connects to many Classes, and each Class connects to many Students.
  • One-to-one: Each Manager connects to one Location, and each Location connects to one Manager.

Learn more about connections types here.

One-to-many types are the most commonly used connection type - they work for the vast majority of relationships.


Let’s go back to our Customer Portal app.

The Customers user role relates to two other objects:

  • Services - each Customer submits Services.
  • Invoices - Customers are issued Invoices to pay for completed Services.

The graphic below shows how you can map out the relationships between your objects for this example.

Customers and Services

Customers can log into their portal to submit Service requests, which then move through the company workflow before being marked as complete. Each Service record represents a single instance of a service being provided to a customer. That makes the relationship between Services and Customers one-to-many - one Customer is related to many Services.

Customers and Invoices

Invoices are created by a company to collect payment from a single Customer for one or more Services completed. That makes the relationship between Invoices and Customers one-to-many - one Customer is related to many Invoices.

Determine Where to Add Your Connections

Once you know what type of connection you need, you determine where to add the connection. In this section we will go over best practices for adding each type of connection.

Though there are two objects, you do not add the connection to both objects. The connection only needs to be added to one of the objects to create a relationship between your records. Which object you add that connection to matters.

Adding a One-to-Many Connection

When working with a one-to-many relationship, you have a parent and a child object. The parent object is the “one” part of the relationship and the child object is the “many.”  

Let’s take the following example: Each Company connects to many Contacts, but each Contact is connected to only one Company.

In this example, Companies is the parent object and Contacts is the child object.

With a one-to-many type of connection, we add the connection to the child object. The reason for this is better workflow options, visual presentation, and data management in your apps. For an example, see the “Which Object to Add Your Connection To” section of this article.  

In this example, we add the connection to the Contacts object, select the Companies objects, and use the default one-to-many configuration.


Let’s go back to our Customer Portal app. We already mapped out our objects and how they are related.

Since all of the connection types in this app are one-to-many, we determine which is the parent and which is the child of each relationship. Then, we add the connection field to the child object.

Customers and Services:

    • One Customer is related to many Services
    • Customers is the parent object
    • Services is the child object
    • Add the connection to the Services object, pointing to the Customers object

Customers and Invoices:

    • One Customer is related to many Invoices
    • Customers is the parent object
    • Invoices is the child object
    • Add the connection to the Invoices object, pointing to Customers object

Adding One-to-One or Many-to-Many Connections

Working with one-to-one or many-to-many connections is more straightforward. You don’t have to worry about parents or children. Rather, you add the connection to the object you will be editing more often.

Let’s say you have many Students assigned to many Classes. Which one would you rather edit? Do you want to add Classes to each Student from the student’s record? If so, add your connection to the Student object.

Add Your Objects and User Roles

You’ve completed all your planning, so it’s time to add your objects and user roles.

Use the green "+” button in the Schema section of the Builder to add your objects and user roles.

If you are adding user roles for the first time, you will need to activate them first. For instructions on activating user roles, see this article.

Connect Your Objects and Records

There are two stages to connecting your records:

  1. Create a connection between two objects
  2. Connect individual records via the connection field.

This article is focused on step #1, planning and creating the connection between your objects. Let’s now add the connections between our objects and user roles.

Connect Your Objects

Navigate to the objects you are adding your connections to. On the right-hand column of the Schema section your Builder, you’ll see a green “+" button.

In the Services object, add a connection and select your Customers user role. On the following popup modal you’ll see the default option is for a one-to-many connection.

Click “Add Connection” to connect Services to Customers. You’ll see the connection you added in the right-hand connections column and as a field in your object.

Repeat this process for your Invoices > Customers connection. For more detailed instructions on adding, editing, and removing connections, see this article.

A connection between two objects is represented as a field in the object the connection is added to. This is called the connection field. From the connection field, you select the record(s) from the connected object you would like to connect the selected record to. You can rename your connection fields to make them more descriptive, by editing that object’s display field in the object settings. This means that you do not have to manage primary or secondary keys in Knack - we manage them for you behind-the-scenes.

Connect Your Records

There are many ways to connect your individual records, from connecting them during an import to using a form view.

To learn about the different methods of connecting the records in your database, see our guide Connecting Records Together.

Notes and Troubleshooting

Using pen and paper to visualize your objects and connections can be very helpful. We encourage you to do your planning outside of Knack before building. 

My app is more complicated than this - how do I plan my connections?

Check out our complex example if your app is more complicated than our example here.

Don’t get discouraged if you don’t get it at first. Understanding connections are often the hardest part of learning how to use Knack! If you still need help figuring out how to connect your objects together, reach out to us at with a list of your objects and a description of what they represent.

What if I need many connection fields between the same two objects?

On rare occasions, you may need multiple connection fields between two objects.Please keep in mind that outside of the limited cases mentioned below, we rarely encourage double connections.

Potential cases include:

  • Livestock: You want to track the mother and father of a horse or other animal. In this case, you can add two connection fields from Animal back to Animal. The first connection field is called Father, the second connection field is called Mother.
  • Students: You want to track two Guardians for each Student. From the Student object, add two connection fields to the Guardian object, renaming them Guardian 1 and Guardian 2.
  • Document or Project Roles: You want to track which user from the Employees user role submits, approves, and manages each Project. From the Project object, add three connection fields to the Employees user role, renaming them Submitter, Approver, and Manager.
  • The Warehouse Manager example listed in our Complex Example article.

If you’re still unsure, please reach out to us at

How do I see what type of connection I have?

If you are learning from one of our many demo apps, you will want to see how the connections are currently set up. You can hover over the connection in the right sidebar of your object to see the relationship type of each connection originating from or going to that object:

You can also click on the connection field to see the type:

More Troubleshooting Tips

For more notes and troubleshooting tips for connections, see this article.

How did we do?

About Connections

Connection Types