Communities: Give Every Team the Task List They Actually Need.
Off-the-shelf project tools were built for teams, not locations.
Pacer starts from a different premise: every task, every discipline, every department, belongs to one location, one source of truth. Communities decide who's cleared to see what inside it.
Grant someone a Community, and Pacer decides, task by task, what shows up in their view, so user access and task access work as two separate layers.
Structure it around lowest necessary access, and everyone gets exactly what their role requires. Nothing duplicated, and nothing hidden from someone who needs it to do their job.
With Communities, Pacer scales inside your organization instead of being renegotiated every time a new team, project, or department wants in.
What's the difference between Communities and "user access rules?"
Communities Are Not User Access. They Are Task Access.
User Access controls which locations a person can reach. Communities control which tasks inside that location they're allowed to see. Both operate at once, and both are necessary.
Grant a person one or more Communities, and Pacer decides, task by task, what belongs in their view. Most customers structure this on one principle, lowest necessary access:
- A vendor sees exactly the handful of tasks assigned to them, nothing more
- A location team sees those same vendor tasks, plus everything at the property level
- Corporate sees vendor tasks, location tasks, and the tasks that belong to corporate alone, brand standards, compliance, sign-off
- A regional VP sees it all, combined, across every property they oversee
- Nothing is duplicated. Nothing is withheld from someone who needs it to do their job
Unclear access creates the same dysfunction spreadsheets did: a wall around each team's slice of the work.
Communities carry this logic into every Dashboard, every Portfolio Health dashboard, every report, so the location holds one truth and access follows the role, not a chart on the wall.
The Pattern to Avoid: Mirroring the Org Chart
Some customers set up Communities by department: Finance sees only Finance tasks, HR sees only HR tasks, and neither sees the other's. It's a tempting default because it's familiar, it's how the org chart already looks.
It's also the wrong instinct, and here's why:
- Departmental silos solve visibility the same way spreadsheets did, by walling off each team's slice of the project
- Finance can't see how a delayed vendor task pushes its own deadline
- Every department gets its own island instead of a shared view of the project
- That's the exact dysfunction most customers came to Pacer to escape
- We support this configuration. We don't recommend it, and we tell customers so directly
When you’re rolling out projects across multiple locations, these gaps slow teams down and introduce risk at every step.
A project succeeds when every discipline can see how its timeline affects the others, not when each department is fenced off with its own private list. Structure Communities around lowest necessary access, not around your departments.
Standardize the Work. Restrict the View.
Off-the-shelf tools force a choice: one board for the whole team, or a workaround for every exception corporate needs.
Split the board to handle vendors, sensitive projects, or department needs, and you split the location. Tasks that belong together scatter across disconnected trackers.
Reporting breaks, because no single view contains a location's true status.
Pacer starts from a different premise: every task belongs to a location, and Communities decide who's cleared to see which piece of it.
No IT ticket. No custom report per role. No dashboard rebuilt every time a new type of user joins the portfolio.
Communities decide the view once. Every future report inherits the rule.