Understanding the Hierarchy in Broker Bridge
- 22 hours ago
- 6 min read
The first article in this series explained what Broker Bridge is. The second covered how to move around the platform. This third document covers the structure that everything in Broker Bridge sits on top of: the hierarchy.
For Ops, this is the most important concept in the platform. Every record you create, status change you make, or support question you answer comes back to hierarchy. If you understand how the structure works, you can answer almost any "where does this person belong" question that comes your way.
This guide is written in plain language. No jargon where it can be avoided.
The Universal Schema
Broker Bridge uses one common structure across all three networks. The order is:
Group → Network → Franchise → Team → Sub-Team → Person
Read that top down and it answers the question "who owns what." DLCG Group owns all three Networks. Each Network (DLC, MCC & MA) owns multiple Franchises. Each Franchise contains Teams. A Team can be split into Sub-Teams if needed. People sit inside these Teams or Sub-Teams.

Two important things to notice in the schema:
Sub-Teams are optional. A person can sit directly under a Team. Sub-Teams only exist when a Team is large enough that it needs internal divisions. Ops create them as needed. More on this near the end of the document.
The lines between people and teams are not all one-to-one. Look closely at the bottom of the schema. Person 2 connects to Team 1 and Sub-team 2-1. Person 6 connects to Team 2 and Team 3 (a different franchise entirely). This is by design. It is the single biggest improvement over the legacy systems, and it deserves its own section.
Many-to-Many: One Person, Multiple Affiliations
In the legacy system, one person could only belong to one place. If an agent was licensed in two provinces and worked under two different DLC franchises, the system had to create two separate records for that person. Two profiles. Two sets of contact details to keep in sync. Two reporting trails. A mess every time someone needed a unified view of that agent.
Broker Bridge fixes this. One person record can belong to multiple Teams, multiple Sub-Teams, and even multiple Franchises across multiple Networks if the situation calls for it.
A real example: Logan Gilmour is licensed in Ontario and Alberta. Under DLC, he works at one franchise in Ontario and a different franchise in Alberta. Legacy systems forced two records. In Broker Bridge, Logan is one person with two affiliations. Both show up under his single profile.
For Ops, the practical impact is:
When someone says, "I work in two places," that is now a valid setup, not a workaround.
When you create a person record, you may need to attach them to more than one Team or Franchise. The platform allows this.
When you look up a person and see multiple Teams or Franchises listed under their profile, that is correct, not a duplicate.
Remember the Multi Teams & Franchises pill on the Manage Person page from the previous document. That pill exists because many-to-many exists.
DLC: What Changed
The structure stays the same depth. The only real change is at the people level.
DLC Legacy

Notice the people layer. Four different titles: Mortgage Agent Level 1, Mortgage Agent Level 2, Mortgage Broker, and Mortgage Agent. Each one tied to licensing and compensation rules outside the platform.
DLC in Broker Bridge

What changed:
Branch Office is now called Team
Branch Leader is now called Team Lead
The four person-level titles (Mortgage Agent Level 1, Level 2, Mortgage Broker, Mortgage Agent) all become Agent
The Principal Broker still sits at the Franchise level, same as legacy.
The collapse to "Agent" is the biggest practical change. If a DLC broker calls and says, "but I am a Mortgage Broker, not just an Agent," they are correct about their license. The license has not changed, only the platform label has. Licensing and compensation continue to live in other systems. Broker Bridge only cares about network position.
MA: What Changed
Two structural levels disappear.
MA Legacy

Two layers in the legacy structure are not in Broker Bridge:
Broker House Region (the "Mortgage Architects Western" container)
Branch (the layer between Team and Sub-Branch)
MA in Broker Bridge
What changed:
Broker House Region is gone. There is no regional layer in Broker Bridge.
Branch is gone as a separate layer.
Sub-Branch is now called Sub-Team.
Branch Leader is now called Team Lead.
Combined roles like "Branch Leader / Lead Planner" become "Team Lead / Lead Planner."
What stayed the same: Person-level role titles are preserved. Lead Planner, Associate Planner, Administrator, and Licensed Admin all keep their names.
If MA people ask why the regional and branch layers disappeared, the simple answer is that they added structural depth without adding operational value at the platform level. Reporting and management still work, just with fewer containers in between.
MCC: What Changed
Two things change at once: the Main Office concept disappears, and the Principal Brokers move up to the Franchise level.
MCC Legacy

The Main Office at 19 Katherine Avenue is structurally different from the Branch Offices. It holds the Principal Brokers and their direct-report agents, all sitting at the same level as the Branch Offices below it.
MCC in Broker Bridge

What changed:
The Main Office concept is gone. 19 Katherine Avenue is now a normal Team, structurally identical to 500 Kings Road, 90 Woodside Lane, or any other Team in the franchise.
Three Principal Brokers (Heather Elliott, Joe Daley, Chris Vey) now sit directly at the Franchise level. They no longer flow through a Main Office.
Branch Office is now called Team.
Broker Owner is now called Team Lead.
Combined roles like "Broker Owner / Operations / Agent" become "Team Lead / Agent" or similar combined Broker Bridge labels.
What stayed the same: Most person-level role titles are preserved. Mortgage Broker, Mortgage Associate, Associate Mortgage Broker, and Agent all keep their names.
The MCC transition is the one most likely to confuse people, because the people who were at the very top of the legacy structure (Principal Brokers) are now in a different position. The structure is cleaner, but it is genuinely different.
Sub-Teams: When Ops Creates Them
The seven hierarchy diagrams above do not show sub-teams in every case, but sub-teams are a real and important part of the platform. They exist for one reason: to give a large Team internal structure when one flat list of people would be too messy to manage.
Sub-Teams sit between Team and Person in the hierarchy:
Franchise → Team → Sub-Team → Person
When to create a Sub-Team:
A Team naturally splits into smaller working groups, often by physical location, specialty, or reporting line
A Team Lead has lieutenants who manage their own slices of the team and need to be reflected in the structure
When not to create a Sub-Team:
The Team is small and everyone reports to the Team Lead directly
The split is informal and not reflected in actual reporting relationships
The "groups" are temporary or project-based rather than structural
Ops controls when Sub-Teams are created. Team Leads and Owners cannot create Sub-Teams themselves. If someone asks for a Sub-Team, the request comes to Ops. Before creating one, check that the request reflects a real structural need, not a workaround for something else.
Once a Sub-Team exists, people are assigned to it the same way they are assigned to a Team. A person can sit directly in a Team or directly in a Sub-Team. Both are valid.
A Note on Role Labels
The container labels (Network, Franchise, Team, Sub-Team) are now standard across all three networks. The role labels at the person level are not.
DLC simplified its person-level roles into a single label (Agent). MA and MCC kept their network-specific role conventions. This is intentional. The schema standardizes the structure, not the language each network uses to describe what its people do.
For Ops, this means:
When you create a Team or Sub-Team, the labels are the same across DLC, MA, and MCC.
When you assign a person, the role you select will depend on which network they belong to.
When you support a question, the structural answer is the same everywhere. The role-level answer depends on the network.

