Why can't drone pilots see every project in the workspace?

Drone pilots should not see every project in the workspace because blanket visibility violates basic access-control principles, leaks data across business units and clients, creates problems when contractors are involved, and weakens the program's ability to defend its operational records under scrutiny. Role-based access control should scope each pilot's visibility to the projects they are assigned to. This is not a software preference. It is how enterprise drone operations work once the program grows past a single team running a single contract.

What "all-pilots-see-all-projects" looks like

In a lot of drone management software, the default state is that every user in the workspace sees every project. The platform was designed for a small operator running a few contracts with a tight in-house team. Adding a pilot means adding a workspace member, and workspace membership comes with full visibility. Every flight log, every project file, every mission output, every piece of client work product is visible to anyone in the account.

That model functions at small scale. It breaks the moment the program grows. A pilot hired for utility inspections sees the public safety contracts running on the other side of the workspace. A contractor brought on for a one-week engagement sees the entire client list. A new in-house pilot, on day one, has the same visibility as the program lead. None of this is operationally necessary, and most of it creates problems the program does not need.

FlybyOps wrote about this directly: the argument is that drone software platforms granting every pilot visibility into every project are not designed for enterprise operations. Pilots should only see the projects they are assigned to.

Where the model breaks

The breakdown happens in four predictable places.

Contractors are the most visible failure mode. A subcontractor hired to fly a single engagement does not need (and contractually should not have) access to the program's full project list. A workspace-wide visibility model gives them exactly that. The program is now relying on the contractor's discretion not to browse client work outside their scope, which is not how access control is supposed to work.

Multi-business-unit operations are the second. A program that runs drone work across utilities, public safety, and survey verticals on the same platform should not have those teams' work commingled at the visibility layer. The utility pilot has no operational need to see public safety incident reports, and the public safety pilot has no need to see utility client deliverables. Separating these matters for data hygiene, client confidentiality, and contractual obligations to each line of business.

Client confidentiality is the third. Some clients explicitly require that work product not be visible to staff working on competing or unrelated engagements. A workspace-wide model makes this impossible to enforce. The program ends up either declining the contractual term or signing it knowing the platform cannot back it up.

Audit defensibility is the fourth. When an FAA inspector or insurance auditor asks how the program controls access to its records, "everyone in the workspace sees everything" is a poor answer. NIST SP 800-53 treats access control as scoping system access to operational need, and an enterprise program is expected to operate the same way.

What proper access scoping looks like

Proper scoping treats assignment as the unit of access. When a Project Manager assigns a Pilot to a job, the Pilot gains visibility into that job and the parent project. When the assignment ends, access is revoked. The Pilot's view of the workspace is the union of their current assignments and nothing more.

Roles still matter on top of this. Admins and Project Managers typically need program-wide visibility because they coordinate across the team. Operation Leads see the projects they own. Pilots and Ground Staff see their assignments. Contractor accounts can be created with the same scoping rules and time-bounded automatically. The platform should capture every assignment change in the audit log so the program can show who had access to what at any point in time.

This shifts visibility from a default state to a deliberate act, which is what enterprise access control means in any other regulated industry. It also makes contractor management simpler, multi-client work safer, and audit defense more straightforward.

Common mistakes

Treating workspace membership as a blanket access grant. Adding a pilot to the workspace should not automatically give them visibility into every project. Assignment to a specific project should be the access-granting event.

Using the same access model for employees and contractors. Contractors typically need narrower, time-bounded access. Programs that onboard contractors with the same permissions as employees create exposure problems for both the contractor and the client.

Not auditing access changes. Assignment grants and revocations are part of the operational record. A program that cannot show when a pilot gained or lost access to a project has lost the ability to defend its access controls under inspection.

FAQ

What if a project genuinely needs every pilot to see it?

That happens occasionally, usually for shared training or program-wide announcements. The right approach is to assign every pilot explicitly to that project rather than relying on workspace-wide visibility as the default. The next project probably does not need the same treatment.

Does this slow down assigning pilots to new work?

No, when the workflow is built around it. Project Managers assign pilots during scheduling, which is something they already do. Access follows the assignment automatically rather than being a separate administrative step.

How does this work for subcontractors?

Subcontractors should be onboarded as scoped accounts with access limited to the engagements they are working on, with access expiring at the end of the engagement. Time-bounded contractor accounts are one of the clearest reasons to want assignment-based access control.

What about pilots filling in for each other?

Filling in is handled by reassignment. When a Pilot needs to cover for another, the Project Manager assigns them to the relevant jobs, which grants the necessary access. The audit log captures the change, and access reverts when the temporary assignment ends.

Closing thought

Workspace-wide visibility is a default that worked at small scale and stops working as the program grows. Contractors, multi-client work, multi-business-unit operations, and audit obligations all push toward access scoping based on assignment rather than blanket workspace membership. A platform built for enterprise drone operations treats this as foundational, not as an advanced configuration option.

If you are running drone operations across multiple pilots, projects, business units, or clients, FlybyOps was built for the operational record problem at the center of regulated drone work. Role-based access control with assignment-scoped visibility, a project and job hierarchy with map-based scoping, a pilot registry with certification and currency tracking, and an append-only audit log are all part of how the platform supports access scoping at enterprise scale.