Imagine a river of data, and you have different information on each side. The bridge model serves as a digital bridge that connects and adds extra details to two data models in your application. It is instrumental in defining relationships between models, that offers a user-friendly mechanism for builders to interconnect various elements within their application flows.

The simplicity of this approach can be shown by the straightforward act of dragging a relational link between two models. However, the true value of the bridge model emerges when there is a need to go beyond plain linkage and enrich the associated data.

Let’s take a shopping cart example. Connecting a buyer and the products with a simple link works, but it’s like saying, “Buyer bought these.” With a bridge model, you can say, “Shopper bought these items, and here’s how many and the total cost.” It’s like adding more details to the story.

The same goes for teams. You might link an employee to a team, but what if that person has different roles in different teams? The bridge model helps here. It’s like saying, “This employee is a developer in one team and a product owner in another.” Simple links can’t tell you that extra info.

Let’s take this example with employee roles and explain it step-by-step. Imagine you are creating an application for your office management using Betty Blocks. You’ll have some employees, their roles, and the teams they are assigned to. To efficiently manage the teams, you want to be able to track which employee belongs to some specific team and which role they have in this team. It seems rather easy at first sight - you need three data models: Employee, Team, and EmployeeRole.

But what if one employee has a double role? For example, John belongs to the team Awesome and the team Shiny simultaneously. Moreover, he’s a developer in the team Awesome and a product owner in the team Shiny. Or imagine if a team changes its name, you’d have to change the names manually for each team member.

This is where the bridge model comes into play. It will store the information about roles and user IDs so that the system can track the information and adjust changes automatically. It’s also highly helpful when you want to avoid redundant data. In our use case here, we’ll rename the team and make sure it has been changed within all the models.

Create a new application and head to the data model menu. Then create three data models: Employee, Team, and EmployeeRole. Add the needed properties to both of your models.

For example, properties for Employee will be the following:

Create the fourth model, let’s call it Function. That will be our bridge model to connect the Employee, Team, and EmployeeRole. As a result, it should contain the data from all three models - their IDs.

Note: Don’t forget to set up model permissions for all the data models you’re going to use.

Go to the schema model view and create relations between our models. As a result, you need to have the following relations:

Now that the models have been created and connected, we can proceed to the next step and build the functionality of the front-end part (via the page builder).

Let’s start by adding data to our models via the page builder functionalities. Go to the page builder and create a new page. We’ll call this Employee overview, as it should contain a data table with all the employees and the create/update forms to add ones to the table and later update their records. Luckily, we have a page template to handle those tasks.

After the page has been created, head to the action builder and set up the permissions for each action that was created automatically along with our template’s create/update/delete forms.

Warning! Although we made all pages, models, and actions public for this example, make sure you’ve settled everything with the authentication and permissions of models and actions on your side!

Okay, it’s time to add employees to our models. They should also be visible within the data table on our newly created page.

You can also view your employee details (if you have those), and update or delete their records from the base using the buttons beside each record.

For this example, we applied the CRUD with a slide-out panel page template but you can also use different page templates or even build this functionality from scratch, depending on your use case.

After the first employee was successfully added to the corresponding model, we’ll add more. Then, using the same template, we’ll create two more pages for adding and managing data within the EmployeeRole and Team models.

For example, this is the Team overview page filled with a bunch of teams we have at our imaginary company. In the same way, we would add more roles to another page.

Now that we have all the necessary data and pages, it’s time to unite every piece into one page. We will create a new page showing all the necessary information from each model that we have, and additionally, we want to be able to add users to a particular team and role, as well as update and delete their records.

To do this, we need a new page with the data table (to show the data from various models), the create/update forms (to enable assigning an employee to a particular role and team), and the delete functionality (for being able to delete each record).

You can build a new page from scratch if you need some specific UI (the ways to do that are explained in this section of the documentation). But for the sake of simplicity, we’ll take a page template yet again. This time it will be the Back office template.

Note: In case you have a big company, it’s better to use Employee.Email property instead of Employee.Name within the update and create forms. Email has a unique value but names can be repeated.

It’s time to test our functionality with some real use-case scenarios. Within our application, we have two primary pages: Employee overview and Management, and each of them is used for a bit different reasons.

1. Using Employee overview, we can add new employees to our company, and provide their name and email address. Additionally, we can update these records from the same page, or delete them.

2. After adding a new employee to the overview, we can go to the Management page and assign them to a role and a team. By clicking the New button, we got a create form in a slide-out panel, where we successfully found Jane Fitzgerald and assigned her as a Developer to the team Shiny.

3. What if Jane changed her job and she’s been replaced by a new employee - Tom Bradly, with the same role (Developer) in the same team (Shiny)? Then we’ll just go to the Management page and replace Jane’s name with Tom’s, and this data will be updated everywhere across our application!

4. Using bridge models also works great with double roles in the organization. You might have noticed that James Dylan is a Product Owner in two teams: Awesome and Jordans, but if we have a look back at the Employee overview page, you’ll see only one record of him.

5. To wrap it up, let us give you one more scenario. Imagine that you wanted to divide Developers in your system into Front-end Developers and Back-end Developers. And you want all the existing Developers to become Front-enders, except for Tom Bradly, who will become a Back-end Developer.

All you need to do in this case is go to the Roles overview and change the Developer role to Front-end Developer, and then just go to the Management page and change the role for Tom Bradly. The rest of the developers will be automatically switched to the Front-end Developer role.

Hopefully, you got the idea of what you can apply bridge models to. Our implementation of these models in the context of office management offered a rather easy solution to this dynamic use case. By bridging the models with employees, roles, and teams, we provided a flexible framework that adapts to a dynamic organizational structure. Besides that, there are dozens of use cases you can work on after getting to know the logic behind bridge models. Good luck, builder!