I once watched a drywall foreman drag a whole week's worth of activities two days to the right on a shared schedule because he thought he was updating his own crew's start date. He wasn't editing his slice. He was editing the master. By the time anyone noticed, the plumber and the electrician had both re-sequenced their week around a phantom delay that never existed. That's a permissions problem, not a people problem. He shouldn't have been able to touch anything outside his trade in the first place.
Access control in scheduling software sounds like an IT chore. On a live jobsite it's the difference between a schedule everyone trusts and a schedule that quietly rots because too many hands can change it and nobody knows who changed what. Get the roles right and the tool disappears into the background where it belongs. Get them wrong and you'll spend your Monday coordination meeting doing forensics instead of planning.
Start With Who Actually Does What on the Job
Before you touch a single settings screen, map your real chain of command onto the schedule. Not the org chart HR keeps — the actual flow of decisions on your project. On most commercial and multi-family jobs it looks something like this:
- The superintendent owns the plan. They sequence trades, set the week, and resolve conflicts. They need full edit on their project.
- The project manager and estimating side care about the look-ahead for procurement and manpower forecasting. They need to see everything, and often to comment, but rarely need to re-sequence field work.
- The foremen and crew leaders need to update status on their own activities — mark things complete, flag a blocker, note that they got two-thirds done — and see how their work ties into the trades ahead of and behind them.
- The subs need to see their commitments and the handoffs that feed them, and nothing about your fee, your other subs' rates, or your internal notes.
- The owner and architect want progress, not the machinery. View-only, cleaned up.
If you can describe those five buckets out loud, you've already designed 90 percent of your permission model. The software's job is just to enforce it.
Separate "See It" From "Change It" — Then Scope Each One
The single most useful distinction in any construction scheduling tool is read versus write, and most access mistakes come from collapsing the two. A foreman who can see the whole three or four week look-ahead is a good thing — you want him planning his crew a couple weeks out. A foreman who can edit the whole look-ahead is the drywall guy from my opening story.
So think in two axes, not one. First, what can this person see? Second, what can they change? The healthiest default for anyone below the superintendent is broad visibility and narrow edit rights. Let people see context so they plan intelligently, but pen their editing to the activities they actually own.
Then scope both by project and by trade:
- Project scope keeps a super on the parking structure from accidentally reshuffling the podium job across town. A regional super or PM might legitimately need several projects; a crew leader almost never needs more than the one they're standing on.
- Trade scope is what saves you from cross-trade sabotage. The framer marks framing; the electrician marks rough-in. Neither can drag the other's bars around. When the tile sub logs in, the schedule should feel like it was built just for them — their activities, the finishes handoff that feeds them, and the punch that follows.
The Sub Login Is Where Most Firms Get Burned
External access deserves its own hard look, because subcontractors are the users most likely to see something they shouldn't. Two failure modes show up constantly.
The first is exposure. Somebody shares a full schedule export and now the mechanical sub can see the GC's internal float, the manpower notes, and — worst case — comments that were never meant to leave the trailer. The rule is simple: a sub sees their own scope and the immediate predecessors and successors that govern their handoffs. That's it. They need to know the deck has to be poured before they set equipment; they do not need to know what you told the owner about the pour being tight.
The second is the opposite — you lock subs down so hard they can't update their own status, so they don't bother, so the schedule goes stale and everyone drifts back to texting. The fix is a narrow write lane: a sub can mark their committed work started, in progress, or complete, and raise a constraint, and nothing else. That single capability is what keeps a weekly work plan alive between coordination meetings. When the field can update its own commitments from a phone in ten seconds, you get real data. When they can't, you get silence and a schedule that lies.
Role Templates First, Exceptions Second
Build from a small set of role templates — administrator, scheduler/super, foreman, sub, viewer — and resist the urge to hand-craft every user. Five clean roles you can explain in a sentence each will serve you far better than fifteen bespoke ones nobody remembers the logic behind. Complexity is its own failure mode; a permission model so intricate that only one person understands it is a model that quietly breaks the week that person is on vacation.
Handle the oddballs as individual exceptions on top of a template, not as new roles. The assistant super who needs edit on two projects instead of one is an exception, not a new tier. Keep the exception list short and reviewed. In tools like LookAheadWall the point of role-based access is exactly this: assign the template, tweak the rare edge case, move on.
Mobile Changes the Calculus
The crew leaders doing the most status updates are doing it from a phone in a stairwell, not a laptop in the trailer. That has two consequences worth designing for.
First, mobile access should be deliberately narrower than desktop. The whole value of a foreman's phone view is speed — see this week, tap done, flag a blocker. You don't want deep configuration or bulk-edit power living behind a fat thumb on a cracked screen. A companion app built for crew leaders should give them their week and their update button, and keep the heavy schedule surgery on the big screen where mistakes are easier to catch.
Second, phones walk off. When a crew leader with schedule access loses a device or leaves the company, you want to kill that access from the admin side immediately, and you want app-level authentication — Face ID or a passcode — standing between a found phone and your project data. Treat the device as untrusted and the account as the thing you actually control.
Audit Trails Turn Arguments Into Facts
Here's the quiet payoff of doing permissions right: when every change is tied to a named account with the right scope, the audit trail becomes trustworthy. Who moved the inspection? Who marked the pour complete when it clearly wasn't? On a schedule where fifteen people share one login or everyone can edit everything, the log is noise. On a properly scoped one, it's evidence.
Use it two ways. Reactively, it settles the "I never touched that" arguments that eat coordination meetings. Proactively, glance at it during your weekly schedule review — a foreman repeatedly editing outside his lane, or a sub who hasn't logged a single status update in three weeks, tells you something about the job before it becomes a delay claim. Change logging and access logging aren't bureaucracy; they're a cheap early-warning system you already paid for.
The Mistakes to Watch For
After enough jobs you see the same permission failures on repeat. Keep this short list on the wall:
- Everyone's an admin. The fastest way to a schedule nobody trusts. If anyone can change anything, no one owns anything.
- The shared login. "We just use one account for the whole crew." Now your audit trail is worthless and offboarding is impossible. One person, one login, always.
- Over-locking the field. Restrict foremen and subs so hard they can't update status, and they'll route around the tool entirely. Adoption dies quietly.
- Stale access. The sub who finished their scope two months ago still has a login. The PM who rolled off the job can still see it. Access should have an expiration mentality — reviewed at every phase change, revoked the day someone leaves the project.
- Undocumented roles. If you can't produce a one-page sheet of who can do what, you don't have a permission model, you have an accident waiting to be discovered.
Make It Boring on Purpose
A good access model is one you stop thinking about. Roles that match the actual jobsite hierarchy, broad visibility so people plan with context, narrow edit rights so they can only change what they own, tight external access for subs, a phone view built for speed, and an audit trail you can actually believe. Set it up once, document it on a single page, and review it at every phase turnover — mobilization, dry-in, finishes, closeout — because the people and trades on the job change and the permissions should follow.
Do that and the schedule stays something the whole team trusts, which is the entire point. Short-interval planning only works if the plan is honest, and the plan only stays honest if the right hands — and only the right hands — can touch it. The framer who dragged the whole week two days to the right taught me that the hard way. It's a lot cheaper to learn it from a blog post.