Broker Bridge: The Ground Rules for Ops

By this point in the series, you have worked through what Broker Bridge is, how to navigate it, and how the hierarchy is structured. You have also walked through the workflows for creating Persons, Franchises, Teams, and Sub-teams, and for transferring people between franchises. You have seen how the platform behaves across each of those workflows.

This article pulls back from the individual workflows and distills the rules that govern all of them. These rules are not features or preferences. They are the structural truths that every Ops decision in Broker Bridge needs to respect. You have already seen each rule in action across the earlier documents. This document names them and groups them so they are easier to remember, reference, and teach.

There are ten rules, grouped into five categories:

1. Existence Rules govern the order in which records can be created.

2. Status Rules govern who controls record activation.

3. Data Integrity Rules govern why every field matters.

4. Distinction Rules flag the pairs of concepts that look alike but mean different things.

5. Process Rules govern how Ops works inside the platform day to day.

Read this article end to end once. Then return to it when something in a workflow does not feel right. If you find yourself thinking "wait, can I actually do this?" the answer almost always lives in one of these rules.

Category 1: Existence Rules

Records in Broker Bridge depend on each other. Some records cannot exist until other records exist first. The platform enforces this order. Knowing the rules upfront saves the work of being stopped mid-workflow.

Rule 1: Person records come first

Every other workflow in Broker Bridge depends on Person records already being in place. A franchise cannot be created without selecting an existing person as the owner. A team cannot be created without an existing person as the Team Lead. A franchise licence cannot be added without an existing person as the Licence Supervisor. A Main Contact must be an existing person.

Whenever a workflow asks for a name, the platform searches for it across existing Person records. There is no free-text path. If the person does not exist yet, the workflow stops until you go and create them.

For onboarding a brand-new franchise group, this means the franchise owner or the principal broker is the first record Ops creates, not the franchise itself.

Rule 2: The hierarchy has a mandatory order

The structural rule reads top-down: every franchise must have at least one team, and every person sits under a team. A franchise cannot directly hold people. Sub-teams are an optional layer when a team needs internal structure, but a sub-team cannot be created without a parent team to attach it to.

This means the order of creation, from outside in, is Franchise, then Team, then Sub-team (if needed), then Person assignment. Going out of order is not possible. The platform will not let you put a person under a franchise that has no team, and the sub-team toggle in the team creation form depends on a parent team being selected.

Category 2: Status Rules

Records do not become active on their own. Activation is a separate decision, and that decision is Ops's alone to make.

Rule 3: All records start Pending; only Ops controls activation

When a Person, Franchise, Team, or Sub-team record is created, its status is automatically set to Pending. The record exists in the platform but is not yet fully functional. Owners, Team Leads, Principal Brokers, and the people in the network cannot change a record's status. Only Ops can.

Activation is also a manual decision, not an automatic one. Even after every creation step is complete and every required field is verified, the system waits for Ops to explicitly open the profile and click Active. This is by design. The platform gives Ops one final point of control before the record goes live across the network.

When you activate a record, you are accepting that the data is accurate, the relationships are correct, and the record is ready to drive downstream activity. That is a real call. Make it deliberately.

Category 3: Data Integrity Rules

Broker Bridge is the hub. Payroll, compliance, marketing, training, external integrations, and reporting all read from it. The fields you enter in Broker Bridge do not stay in Broker Bridge. They flow outward.

Rule 4: Effective Date is the real-world date, not the entry date

If a person joined a franchise on May 5, the Effective Date on their franchise association is May 5, regardless of whether you enter the record into Broker Bridge that day, that week, or that month. The same applies to franchise contracts, licences, and team start dates.

Effective Date is the date the relationship became real in the world, not the date Ops captured it in the platform. Getting this wrong creates compliance gaps and reporting errors that are hard to trace back later.

Rule 5: Data accuracy has downstream consequences. Capture optional fields when available

Cleaner data in Broker Bridge means cleaner payroll, accurate marketing, correct training assignments, working external integrations, reliable reporting, and a functioning public agent website. A typo in a Velocity Firm Code breaks deal flow. A wrong Profile Type breaks reporting. A misconfigured external ID breaks a credit pull. There are no low-stakes fields in the hub.

Fields marked optional in the platform are often optional for workflow convenience, not because the data does not matter. Legacy IDs, SINs, number of deals funded, social media links, and similar fields should be captured at creation when the data is available. Skipping them is fine when the data is genuinely not on hand. Skipping them out of speed creates future cleanup work that costs more time than the original capture would have.

Category 4: Distinction Rules

Some fields and concepts in Broker Bridge look similar but mean different things. Mixing them up is one of the most common sources of error in Ops work.

Rule 6: Don't conflate concepts that look alike

Watch out for these four pairs in particular:

Operating Name, Company Legal Name, and Licence Operating Name. Three different things. Operating Name is the name used in daily operations and marketing. Company Legal Name is the official legal name of the company in the contract with the network. Licence Operating Name is for cases where a brokerage trades under a different name on a specific provincial licence. The platform plans to discontinue Licence Operating Name in a future release, but for now all three exist as separate fields and need to be captured separately.

Profile Type: Agent vs Staff. Structural, not casual. Agents are mortgage originators. Staff are administrative or support roles that work for the brokerage without originating deals. The choice affects how the person appears in reports, what they can do in the platform, and how external systems treat their record. Selecting the wrong option creates downstream problems that are tedious to unwind.

External ID vs External Account. Different concepts in different creation steps. External IDs are credentials for operational systems that Broker Bridge connects to (Velocity, Expert, Equifax, TransUnion, Purview). External Accounts are third-party memberships and affiliations (currently MPC). Step 6 of Person creation captures the first. Step 7 captures the second. The two are not interchangeable.

Container labels vs role labels. Container labels (Network, Franchise, Team, Sub-team) are standardized across DLC, MA, and MCC. They mean the same thing in all three networks. Role labels at the person level are not standardized. DLC collapsed its four legacy person-level titles into a single label called Agent. MA and MCC kept their network-specific role conventions. When you support a question, the structural answer is the same everywhere. The role-level answer depends on the network.

Category 5: Process Rules

These are the operational habits that prevent the bulk of the cleanup work. None of them are enforced by the platform. All of them are enforced by experience.

Rule 7: Many-to-many is valid. Multiple affiliations are not duplicates

A person record can belong to multiple Teams, multiple Sub-teams, and multiple Franchises across multiple Networks. This is the single biggest improvement Broker Bridge offers over the legacy systems. When a profile shows multiple associations, that is correct, not a sign of a duplicate to clean up. The MULTI TEAMS & FRANCHISES pill exists because this is real and supported.

When someone says "I work in two places," that is a valid configuration now, not a workaround.

Rule 8: The human conversation comes before the system action

For transfers in particular, but really for any change that affects a person's affiliation or status, the conversation with the people involved must happen before the system change. Broker Bridge surfaces a reminder at every step of the transfer flow for exactly this reason.

The platform handles the data change. It does not handle the relationship between a broker, their current team, and the team they are moving to. The human conversation needs to happen separately, and it needs to happen first. The consequence of skipping that conversation lands on Ops afterward, and the cleanup is rarely just a system change.

Rule 9: Nothing is committed until the final commit button

Across every creation workflow in Broker Bridge, there is a final commit button: Create Person, Create Franchise, Create Team, and so on. Until that button is clicked, the work is not saved to the platform as a complete record.

This is useful in two directions. It means you can close the browser mid-workflow and come back later through the Save Draft option without losing your place. It also means that until you click commit, no downstream system has been told this record exists. The record cannot be used, queried, or linked to. Make sure you reach the commit button before considering the task done.

Rule 10: When in doubt, escalate. Don't improvise

A confident wrong answer from Ops creates more cleanup work tomorrow than a "let me check on that and come back to you" today. Broker Bridge is structurally precise, and the platform expects Ops to be the same. If a situation does not fit the documented pattern, do not guess at the answer.

Structural questions go to the Broker Bridge product team. Document the question and the answer once you have it, so the next time the same question comes up, Ops has the answer ready and the pattern documented.

Quick Reference: The Ten Rules

For fast review or training reinforcement, here are the ten rules in one place:

1. Person records come first

2. The hierarchy has a mandatory order: Franchise, then Team, then Sub-team (if needed), then Person

3. All records start Pending; only Ops controls activation

4. Effective Date is the real-world date, not the entry date

5. Data accuracy has downstream consequences. Capture optional fields when available

6. Don't conflate concepts that look alike: Operating vs Legal vs Licence Operating Names, Agent vs Staff, External ID vs External Account, container labels vs role labels

7. Many-to-many is valid. Multiple affiliations are not duplicates

8. The human conversation comes before the system action

9. Nothing is committed until the final commit button

10. When in doubt, escalate. Don't improvise