Planning Roles, Permissions, Teams, and Pipelines

This guide helps you design a clean, scalable access model in MeasureSquare CRM so:

• People see what they need

• People can do what they’re responsible for

• Admins don’t have to constantly create “special cases”

• The system stays easy to maintain as you grow

For mid-to-large organizations (10–15+ users), roles, teams, and pipelines become intertwined, so it’s best to plan them together.

(For smaller teams, refer to: CRM Implementation Methods: Roles/Permissions/Teams (<10 Person teams).)

1) The three building blocks (think: WHAT, WHOSE, WHERE)

A) Roles & permissions = What can someone do?

Roles define:

• Which modules a user can access (Projects, Quotes, Bids, POs, WOs, etc.)

• Which actions they can take (View / Edit / Delete)

This is your capability layer: what someone is allowed to do in the CRM.

B) Teams = Whose records can they see/edit?

Teams are how you group users for visibility and ownership boundaries.

Key concept: When a module’s permission scope is set to Team, access becomes additive because users can belong to multiple teams:

• A user with Team-scoped access can access records owned by any team they belong to

• Adding someone to an extra team expands their visibility and edit reach across Team-scoped modules

Why this is powerful:

• You can keep most roles safely set to Team scope (instead of All)

• You expand access by team membership, not by creating one-off roles

Key takeaway: Teams become access groups, not just org charts.

C) Pipelines (and pipeline access by team) = Where does work move, and who’s allowed in that lane?

Pipelines are your workflow lanes (stages that work moves through). In MeasureSquare CRM, pipeline access can be controlled by team, which is one of the best ways to prevent users from working in the wrong lane.

There are two pipeline types:

1) Sales pipelines (must include Won + Lost)

Sales/estimating pipelines should be created as Sales pipeline type and must include:

• A Won stage

• A Lost stage

Use Sales pipelines for anything that is still “pre-award”:

• Leads / opportunities

• Bid pursuit

• Anything before a contract or financial commitment exists

2) Other pipelines (no Won/Lost)

Other pipelines do not include Won/Lost stages.

Use Other pipelines for workflows where the project is already real work-in-motion:

• Execution / WIP

• Procurement tracking

• Installation tracking

• Billing / closeout tracking

Simple rule: If it’s not awarded yet → Sales pipeline. If it’s real work after award → Other pipeline.

2) Recommended planning sequence (do this before configuration)

Step 1 — Define your business lanes

For most contractors, the typical setup is two lanes:

1. Sales / Estimating (pre-award)
   Lead → opportunity → takeoff → quote/bid → follow-ups → close

2. Project Execution (post-award)
   Kickoff → procurement → install → change orders → billing/closeout

As your organization grows, it can make sense to split lanes further so ownership and workflows stay clean. A common expanded lane list is:

• Sales (pursuit / opportunity management)

• Estimating / Bid Production

• Procurement / Purchasing

• Execution / Project Management (WIP)

• Installation / Field Ops

• Finance / Accounting

• Leadership visibility

These lanes become your pipelines and your access boundaries.

Step 2 — Decide what teams represent

Because users can be in multiple teams, pick a team model that stays simple and supports clean access.

Common primary team models (pick one main pattern):

• By branch/region (Dallas, Phoenix, LA)

• By market segment (Residential, Commercial)

• By division/business unit

Then optionally add overlay teams to expand access safely:

• Estimating – All

• Purchasing – All

• Accounting – All

• Leadership – All

• Special Project Pod teams

Step 3 — Decide how many pipelines you truly need

Create pipelines only when the stages and owners truly differ.

Typical structure:

• One or more Sales pipeline(s) (Sales type, with Won/Lost)

• One or more Execution pipeline(s) (Other type, no Won/Lost)

If your org has meaningfully different workflows (ex: Residential vs Commercial), parallel pipelines can make sense — still following the Sales vs Other rule.

But avoid duplicate pipelines for processes that are basically the same. Often, teams + pipeline filters already solve it.

3) Scope made simple: All vs Team vs Owned

All

Role can access all records in that module
Use sparingly (admin, leadership oversight, centralized departments)

Team

Role can access records owned by any team the user belongs to
This is usually the most scalable option for growing orgs

Owned

Role can access only records they personally own
Useful for strict boundaries or personal workflows

Multi-team best practice: Default most roles to Team scope, then expand access by adding teams (or overlay teams) rather than flipping people to All.

4) Using teams + pipeline access together (the safest scalable model)

The cleanest pattern: Primary teams + overlay teams

Primary teams (boundaries)

• Dallas

• Phoenix

• LA
  (or Residential / Commercial, etc.)

Overlay teams (shared services / safe access expansion)

• Estimating – All Branches

• Purchasing – All Branches

• Accounting – All Branches

• Leadership – All Branches

Why this works:

• Primary teams keep boundaries intact

• Overlay teams let specialists work across the org without giving “All” access

• Pipeline access by team keeps people operating in the correct workflow lane

5) Practical blueprint: roles + team membership + pipeline access

Below is a proven structure you can adapt.

Role 1: Admin

Purpose: setup, governance, corrections
Teams: usually Leadership/All
Pipeline access: all
Permissions: broad module access including configuration tools

Role 2: Sales

Purpose: manage leads/opportunities, coordinate quotes, close deals
Teams: usually one primary team; sometimes multiple if they cover multiple markets
Pipeline access: Sales pipelines (Sales type) for their team(s)
Permissions pattern: strong sales module access; limited procurement/execution/finance (often view-only if enabled)

Role 3: Estimator

Purpose: produce bids/quotes/diagrams; manage estimating workflow
Teams: one branch team OR overlay “Estimating – All”
Pipeline access: Sales-type bid pursuit pipelines (with Won/Lost)
Permissions pattern: strong estimating modules (quotes, bids, diagrams, products/pricing as needed)

Role 4: Project Manager / Operations

Purpose: run execution and delivery
Teams: typically one branch team; multiple if managing across branches
Pipeline access: Execution pipelines (Other type)
Permissions pattern: strong operational modules (projects, schedule, work orders, change orders, submittals, etc.); limited access to sales pursuit modules (often view-only)

Role 5: Purchasing

Purpose: vendors, purchase orders, procurement workflows
Teams: branch-specific or overlay “Purchasing – All”
Pipeline access: Execution pipelines (Other type); optional purchasing-specific “Other” pipeline if you want a dedicated procurement lane
Permissions pattern: strong purchasing modules; enough project visibility for context

Role 6: Accounting / Finance

Purpose: invoicing, bills, expenses, closeout, reporting
Teams: branch-specific or overlay “Accounting – All”
Pipeline access: Execution pipelines (Other type)
Permissions pattern: strong finance modules; view access to ops modules needed for validation

Role 7: Executive / Read-only

Purpose: visibility without operational risk
Teams: often “Leadership – All” overlay
Pipeline access: all pipelines
Permissions pattern: view across key modules; minimal edits

6) How to apply your permission list during implementation

If you already have a long module permission list (Project/Quote/Vendor/Work Orders/Tasks/Products/Analytics, etc.), don’t try to make it perfect for everyone.

Use it like this:

1. Treat it as your baseline template

2. Split it into 3–8 roles

3. Tighten sensitive modules for most users

4. Expand only for roles that truly need it

5. Keep most operational roles on Team scope and expand access using team membership

7) Implementation patterns that work well with multi-team membership

Pattern A: Branch teams + centralized specialists

• Primary teams: each branch

• Specialists: belong to multiple branch teams or an overlay team
  Best for: multi-location orgs with shared resources

Pattern B: Segment teams (Residential / Commercial) + cross-segment roles

• Primary teams: Resi, Commercial

• Some users (leadership, senior estimator) belong to both
  Best for: very different workflows by segment

Pattern C: Project pod teams for high-stakes jobs

• Create a team for a major project

• Add Sales, PM, Purchasing, Accounting to that team

• Keep roles Team-scoped
  Best for: complex projects where collaboration must be contained and explicit

8) Testing and rollout checklist

• Create teams (primary + overlays)

• Create pipelines:

  • Sales pipelines (Sales type, include Won/Lost)

  • Execution pipelines (Other type, no Won/Lost)

• Assign pipeline access by team

• Create roles (6–8 persona roles)

• Pilot with real users:

  • Can each role complete their job end-to-end?

  • Did multi-team membership accidentally create too much access anywhere?

• Adjust and lock your standard role set

• Document the rules:

  • When to add someone to an extra team

  • Who is allowed to see which pipelines

  • Which roles can edit which modules