Nobody thinks about permissions until the day a drywall foreman drags a plumbing activity two days to the right because the wall was in his way, and now the whole trade-flow sequence downstream is wrong and three subs are showing up on days the work isn't ready. That five-minute mistake cost you a morning of phone calls. It happened because somebody had edit rights they never should have had.
Permissions are boring right up until they aren't. Get them wrong in one direction and you've got a schedule anyone can quietly break. Get them wrong in the other direction and every trivial status update funnels through one superintendent who's already buried. The goal isn't "lock everything down" — it's matching what each person can touch to what they're actually responsible for. This is a walk through how to think about that on a real project.
Start With the Ownership Chain, Not the Feature List
Most software presents permissions as a grid of checkboxes — view, create, edit, delete — across a list of features. That's the wrong place to start. Start with the chain of who owns what on your job.
The GC owns the schedule logic. Superintendents and the scheduler own the sequence — which activity feeds which, and where the buffers sit. A trade foreman owns the status of his own work and nothing else. The owner and design team own the right to look and to ask questions. Once you've written that down for your project, the checkbox grid mostly fills itself in. Every permission decision is really the question: "does this person own this thing, or do they just need to see it?"
When you skip this step and configure by feature, you end up granting edit access because it felt convenient in the moment, and six weeks later you can't remember why the concrete sub can move milestones.
The Three Access Levels That Cover 90% of People
You can overthink this. In practice, almost everyone on a project fits into one of three buckets, and if you get these three right you've solved most of the problem.
- Schedule owners — superintendents and schedulers. They create and modify the look-ahead, connect trade flows, set durations and buffers, and move work when reality changes. This should be a short list. On a typical mid-size job it's two or three people, not ten.
- Status updaters — trade foremen and crew leaders. They can mark their own activities started, in progress, or complete, and flag when something's blocking them. They cannot move activities, change logic, or touch another trade's work. This is the biggest group and the one people most often over-permission.
- Read-and-comment — owners, architects, PMs who aren't running the field, and any sub who needs to see the plan but not drive it. They see the current weekly work plan, and ideally they can leave a comment or a question, but they can't change anything.
The mistake I see over and over is collapsing "status updater" into "editor" because the software made it easy. Letting a foreman update his own activity status is exactly right — it's how you get real field data flowing back into the plan instead of stale guesses. Letting that same foreman drag activities around the calendar is how the schedule quietly rots.
Why Read Access Should Be Generous
Here's a rule that saves you grief: when in doubt about view access to the schedule, open it up. A short-interval schedule is not a secret. The whole point of a weekly work plan is that everyone downstream can see what's coming and stage their crews, materials, and equipment for it. A plumber who can see that framing on the third floor finishes Thursday will show up Friday ready to go. A plumber who has to call and ask will show up whenever he gets around to it.
Broad read access almost never creates a security problem, and it removes an enormous amount of coordination friction. The sequences, the durations, the who's-where-when — that information wants to be visible. Save your restrictions for the things that actually need protecting.
What Actually Needs Locking Down
Schedules should be visible; money and internal notes should not. The genuinely sensitive stuff on a construction project is a shorter list than people assume:
- Cost data — budgets, cost reports, change-order pricing, sub buyout numbers. A trade partner has no business seeing what you're paying another trade, or your markup. Keep financials to GC office personnel.
- Internal resource planning — your own crew loading, labor allocations, and the notes where your super wrote "this sub is behind and we may need to supplement." That's for the GC, not the subs.
- Cross-trade views a sub doesn't need — a foreman needs to see his work in the context of the trades immediately around him. He usually doesn't need the full project-wide resource picture, and giving it to him just invites second-guessing.
Submittals and RFIs are the opposite case — those generally want broad access, because trades need visibility into anything that affects their scope. Filter them by trade so people see what's relevant to them, but don't wall them off. Information that affects a sub's work, given to the sub late, is how you get a change order.
Sub Access: Enough to Participate, Not Enough to Wander
Bringing subcontractors into the same scheduling tool the GC uses is one of the highest-leverage moves you can make. When a foreman updates his own status directly instead of texting the super who then updates it, the plan stays current and the phone stops ringing. But sub access needs deliberate boundaries.
Scope a sub's login to their assignments: they see and update their activities, they see the surrounding sequence so they can coordinate, and that's the fence line. They don't see other subs' pricing, they don't see your internal GC comment threads, and they don't get to reschedule around their own convenience. A good tool — LookAheadWall included — lets you give a crew leader exactly this on a phone in the field: their week, their activities, a way to mark progress, without handing them the keys to the whole schedule.
One caution from experience: when you invite a sub in, walk their foreman through it in person the first time. The technical permission is only half the job. If he doesn't understand that dragging an activity changes the plan for everyone, he'll do it once out of habit. Two minutes of "here's what you can touch and here's what you shouldn't" prevents the phone-call morning I opened with.
Owners and Architects: Visibility Without a Steering Wheel
An owner who can watch the look-ahead update week over week is an owner who trusts you and calls you less. Give them read access to the schedule, and give them a way to comment or ask a question — but keep it read-only on the plan itself. You do not want an owner or an architect accidentally changing a date and then a sub acting on it. Commenting lets them engage; edit rights let them create confusion. Design-team access usually centers on drawings and RFI responses anyway, not on driving the field schedule, so scope them there.
Field vs. Office, and the Mobile Question
The person in the field and the person at the desk often need different things. A superintendent walking the job wants to update status, flag blockers, and see the next few days fast, from a phone. A PM at the office may need the fuller picture — reporting, look-ahead planning across weeks, coordination across projects.
It's reasonable for mobile access to be leaner than desktop. Some actions — finalizing certain records, anything that needs review — can be office-side. Just don't cripple the field. The field is where the real information lives; the person who can see the wall is the person whose status update you most want to be true. Make the common field actions dead simple on a phone, and push the heavy planning to where there's a keyboard and a big screen.
Audit Trails Are Only as Good as Your Permissions
A change log that says "activity moved" is useful. A change log that says "activity moved by the drywall foreman" is a signal that your permissions are wrong. The two work together: the audit trail tells you what happened, and clean permissions make that history mean something, because the actions it records are all authorized ones.
If you ever have to reconstruct why the schedule looks the way it does — for the owner, for a claim, for a delay analysis — you want that history to read like a series of deliberate decisions by the people responsible for them, not a scramble of everyone editing everything. Good permission structure is what makes your audit trail defensible instead of just a list of chaos.
Practical Rules of Thumb
- Start tight, loosen on request. It's far easier to grant access when someone asks than to claw it back after they've made a mess. Default new users to the minimum their role needs.
- Match the role to the job, not the person. Configure by function — superintendent, foreman, owner — so that when people rotate on and off the project, you're assigning a known role, not rebuilding permissions from scratch.
- Re-check at each project phase. The permission set that's right during framing may be wrong during finishes and closeout, when different trades and different sensitivities come into play. Revisit it when the phase changes, not just at kickoff.
- Keep the editor list short and visible. Know, at any moment, exactly who can move the schedule. If you can't name them off the top of your head, the list is too long.
- Write down the non-obvious calls. When you make an unusual permission decision — a JV partner who needs cross-company visibility, an owner's rep who gets extra access — note why. Future-you, or your replacement, will thank you.
None of this is complicated once you stop thinking of permissions as a security checklist and start thinking of them as a map of responsibility. The schedule should be visible to nearly everyone, editable by a disciplined few, and updatable — status only — by the people doing the work. Protect the money and the internal notes, open up the plan, and give every foreman a clean, obvious way to tell you the truth about his work. Do that, and the software stops being a place where things break and becomes what it's supposed to be: the shared, trustworthy picture of what the crews are building this week.