How to set up multi-office CRE listing permissions and pipeline reporting

Multi-office brokerage management has two competing needs. Local teams need a useful view of their own deals. Corporate leadership needs a reliable picture of the whole firm. Access rules add a third concern: a broker should not see or change information simply because a deal appears in a shared pipeline.

Core Listing supports multi-office brokerage management with firm-wide and office-level pipelines. That gives a brokerage a structure for local and corporate deal tracking. But pipeline structure is not the same as role-based permissions. The available product facts do not specify permission granularity or reporting fields. Treat both as setup questions to verify, not as controls to assume.

1. Decide who owns each listing

Start with the operating model, not the software. For every office, name the person accountable for listing accuracy and the person who can resolve a cross-office dispute. Then define ownership for deals involving more than one office. A property should have one accountable office even when several teams contribute.

Write down the rules for common cases: a broker transfers offices, a listing is shared across regions, or a corporate team takes over a deal. Decide who can change the assigned office and who must be notified. These decisions prevent pipeline totals from changing simply because two offices use different conventions.

2. Map roles to the access each job needs

Make a short access matrix before configuring user access. Keep it about work, not seniority. For example, a broker may need to work on assigned listings; an office lead may need visibility across that office; a marketing coordinator may need listing information to prepare marketing materials; and corporate leadership may need firm-wide pipeline visibility.

For each role, specify whether the person needs to view, create, edit, or administer information. Also note any information that should remain restricted. Do not assume that a role name in your policy corresponds to a permission in the product. Ask which access levels Core Listing can enforce, and match the matrix to the controls actually available.

If the available controls cannot enforce a restriction, record that gap and choose a separate process to manage it. A written policy or an office label is not a technical barrier. Do not describe a deal as restricted if users can still reach it through the system.

3. Separate office work from firm-wide oversight

Set up each office pipeline around the steps its brokers actually use, then agree on a common meaning for every stage that corporate leadership will compare. A local team may use extra steps for its own workflow. The stages used in firm-wide review should still mean the same thing in every office.

Define stage entry and exit rules in plain language. For instance, decide what evidence makes a deal active, under contract, or closed. Do not rely on stage names alone. If one office marks a deal active at launch and another does so only after buyer engagement, their totals are not comparable.

Core Listing’s firm-wide and office-level pipeline structure can support this division between local tracking and company-level oversight. Confirm during setup how office records appear in the firm-wide view and what information is available there. Do not assume that every field, filter, or report can be customized.

4. Test the access policy with real scenarios

Before rollout, check the proposed rules against a few ordinary situations. Use a listing owned by one office, a shared deal, and a deal that should be visible only to a limited group. For each, ask a representative user from each role what they should be able to see and change.

Then verify the behavior with the product’s available access controls. Check both the intended access and the restrictions. A user who can open a listing but should not edit it is a different case from a user who should not see it at all. Include office transfers and departures in the test plan so access does not drift as teams change.

Keep the test focused. The goal is not to prove every possible configuration. It is to confirm that the rules your brokerage depends on are enforceable before sensitive listings and pipeline data rely on them.

5. Make corporate pipeline reviews consistent

Choose a small set of firm-wide measures and define each one. Specify what counts as an active listing, which date anchors a pipeline review, and how shared deals are counted. Decide who corrects missing or inconsistent information, and set a regular deadline for offices to update their records.

Use the firm-wide pipeline for the corporate conversation and office-level pipelines for local follow-up, subject to the reporting and access options confirmed with Core Listing. If a required roll-up is not available, do not present an informal spreadsheet as a verified system report. Identify its source, owner, and update date.

6. Review the model as the brokerage changes

Revisit office ownership, access rules, and stage definitions when the brokerage adds a branch, changes reporting lines, or adopts a shared-deal process. Ask each office lead to flag exceptions. Corporate leadership should review whether the firm-wide picture still reflects the same definitions across branches.

The practical test is simple: local teams can maintain their own pipeline, leadership can review the whole firm, and access matches the brokerage’s stated rules. Core Listing provides the multi-office pipeline structure. The brokerage still has to define the operating rules and confirm which permission and reporting controls are available before relying on them.