In-depth data model structure
      Back to home
      1. Betty Blocks Documentation
      2. Use-case guides
      3. In-depth data model structure

      Using a bridge model in your page builder forms

      Learn how to build a bridge model in the page builder form that enables one to pick values from two different data sources.

      What is a bridge model?

      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.

      Use case described

      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.

      Creating 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.

      Building relations

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

      • Many Functions belong to one Employee

      • Many Functions belong to one EmployeeRole

      • Many Functions belong to one Team

      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).

      Creating pages and data

      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.

      First overview page

      1. Create a new page using the CRUD with a slide-out panel template

      2. Choose the name and the page type

      3. Pick up the Id, Name, and Email properties in the configuration window

      4. Press Create page

      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!

      Adding new employees

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

      1. Compile your page by pressing Play and your front-end page should open in a new browser window.

      2. Click the New button and you’ll be able to add a new user by filling in the Name and Email fields.

      3. Press Save to finish adding your new employee

      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.

      Creating more pages and data

      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.

      Creating Management 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.

      1. Let’s build our new page with the Back office template and call it Management.

      2. Choose the Function (our bridge model) and select the Id (Function) and the following related properties:

        1. Employee.Name

        2. EmployeeRole.Name

        3. Team.Name

      3. Click Save

      1. After the page is created, we need to reconfigure the create and update forms in the record view

      2. Unlock the page for editing (lock icon at the button of the options window)

      3. Change the page view to Record view and select Create tab:

        1. Select one of the autocomplete components in the slide-out panel

        2. Set the following values in the autocomplete component options:

          1. Change the label name (to Select employee)

          2. Set the value to Employee.Id (this will enable the system to pick up the right employee)

          3. Choose the corresponding model in the label for options dropdown (Employee.Name for the first autocomplete, etc.) so that we can see the employees' names in the dropdown

          4. Repeat the same process for each autocomplete form choosing the labels, values, and label for options accordingly

      1. After you’re done, compile the page to see if it works the way you want

      2. Come back to the page options view to Record view and select the Update tab. Repeat the actions from the step 3 for this tab.

      3. Change the names for tabs and data table columns to your liking

      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.

      Use case applications

      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!