Role-based access for contractors: 6 drone platforms compared
How DroneDeploy, DJI FlightHub 2, FlytBase, Aloft, AirData and FlybyOps handle role-based access for contractors: what an outside pilot becomes, what they see, and how access ends.
DroneDeploy, DJI FlightHub 2, FlytBase, Aloft, AirData and FlybyOps all offer role-based access control, so "does it have RBAC?" won't separate them. For a drone program that uses contractor pilots, three narrower questions do separate them: does a contractor see only the jobs they're on, does their access end when the contract does, and does the record show who did what.
Each platform answers them differently, and the answers sit in six separate sets of docs. Here they are side by side.
How do drone platforms handle contractor access?
| Platform | Roles it documents | What an outside user becomes | How access is scoped | Removal and audit, as documented | Plan |
|---|---|---|---|---|---|
| FlybyOps | Administrator, Project Manager, Operations Lead, Pilot, Ground Staff | Contractors are granted access through the same roles, without seeing unrelated projects | By project and job, with one role per person across the workspace | An Administrator removes the person in one action, ending their access to every project; their records keep their name, and an append-only audit log on every plan keeps their history | Contractor access controls from Business; SSO and SCIM on Enterprise |
| DroneDeploy | Owner and Admins, Members, External Users, with Pilot, Upload Only, Analyst and Viewer permissions | An External User: not a member of the organization, granted access to specific projects to view, edit or upload | By project or folder | Removing an external user ends their access to shared projects and folders, and what they uploaded stays with you; Enterprise admins can export audit activity logs | RBAC and SSO on Enterprise |
| DJI FlightHub 2 | Five organization roles: super administrator, organization administrator, device maintainer, organization member, temporary member; project roles set separately | A Temporary Member: someone who joins a project without being an organization member, with limited permissions in that project | By project; organization and project permissions are independent | Administrators can delete members | Custom project roles aren't in the Standard edition |
| FlytBase | Owner, Admin, User | No contractor user type in the docs; Guest Share sends one drone's live video to outsiders for a set time, without access to the organization | By site: users operate only on their sites, and Owners and Admins see every site | Owners and Admins can remove users | Not in its role and site docs |
| Aloft | Custom roles, as many as needed; a fixed Primary Admin; a Default Pilot role that starts out limited to the pilot's own data and logs | You build it from a custom role | A separate account, or tags and permissions inside one account | Not in its roles and teams help pages | Not in its roles and teams help pages |
| AirData | Role-based access by team, region or business unit | Not described on its pricing page | By team, region or business unit | Not described on its pricing page | Enterprise |
Two of the six name an outside user type: DroneDeploy's External Users and DJI's Temporary Members. The rest build contractor access out of roles, sites or teams. The plan matters as much as the model: DroneDeploy puts role-based access on Enterprise, FlightHub 2's Standard edition has no custom project roles, and FlybyOps adds contractor access controls from the Business plan.
What should a contractor be able to see?
The jobs they're assigned to, the documents those jobs need, and nothing else. They shouldn't see other contractors' work, the rest of your asset portfolio, or your customers. The default is no access, added per assignment. In FlybyOps, a flight plan carries its permits, risk assessments and customer documentation, and documents have role-based access, so a contractor pilot opens the job and finds what they need on it. It's the rule we lay out for your own team in why pilots should only see the jobs they're assigned to, applied to people who aren't on your payroll.
How much separation you need depends on the contractor. A firm that runs a whole inspection program for you, with its own pilots, planners and reports, may belong in an account of its own: the "hard wall" Aloft describes. A handful of contractor pilots flying named jobs alongside your own team fit project-scoped roles.
Whichever platform you trial, log in as the contractor and look at what's on the screen. Aloft, for one, says its permissions are "not as restrictive as the account separation," and pilots may see some aircraft or authorization details from users outside their team.
How do you set up contractor access in FlybyOps?
Give a contractor one of the five built-in workspace roles, then scope them to their projects. Each person holds one role across the whole workspace, never a different role per project. The roles:
- Administrator. Manages users, billing, storage, projects, permissions and settings, and sees every operational record.
- Project Manager. Creates and manages projects, assigns pilots and ground staff, reviews completed work and manages documentation.
- Operations Lead. Runs day-to-day work on their own projects, without automatic visibility into unrelated sites or customers.
- Pilot. Sees the work assigned to them: their jobs, flight logs, tasks, job reviews, and the risks and incidents they report.
- Ground Staff. Reports incidents, flags risks and records observations without full project visibility.
A contractor pilot is a pilot. They take the Pilot role, a contractor's ground crew takes Ground Staff, and what changes is what you scope them to: the projects they're working on. A pilot assigned to one construction site doesn't automatically see another customer's operations, so two contractors scoped to different projects don't see each other's work. The contractor firm's own lead runs their crews day to day. The lead can add and remove Pilots and Ground Staff on jobs in their projects and staff them on flights. The lead can't invite people to the workspace or add anyone to a project; your Administrators and Project Managers do that. Nor can the lead remove anyone from the workspace: only an Administrator can.
If you're the contractor and serve several clients, the same scoping keeps their work apart (data isolation for multi-client drone work). The full breakdown is on the roles and permissions page.
What happens when the contract ends?
Two things should happen: the contractor's access ends with the work, and the records they made stay with you, under their name.
In FlybyOps, ending it is one action: an Administrator removes the person from the workspace, and their access to every project, job, flight and incident in it ends at once. There's no separate deactivate setting to forget, and a Project Manager can't do it. Their records stay: flights, incidents, risks, documents and jobs still show their name, and the audit log keeps their history. Their FlybyOps login still works for any other workspace they belong to. If you manage accounts from an identity provider, FlybyOps Enterprise includes SSO and SCIM provisioning.
Test it before you sign, on any platform. Add a test contractor, give them one job, then remove them. Check two things: they can't open the job any more, and the flight log they filed is still there under their name.
How do you prove the access rules held?
With an audit log. When a client, an insurer or a security reviewer asks who worked on their asset, a list of roles won't answer them. A log of actions will.
FlybyOps keeps an append-only audit log on every plan. It shows who created a project, who updated a risk, who approved a document, who submitted a flight log, who investigated an incident and who changed an operational record. With each contractor pilot on their own login, every record they create carries their name.
FAQ
What's the difference between RBAC and per-user permissions?
Per-user permissions set access person by person. RBAC sets it once per role, and each new user inherits the role's access. With ten contractor pilots, that's one Pilot role to get right instead of ten custom setups.
Which FlybyOps plan do I need for contractors?
Contractor access controls come with the Business plan and above. Enterprise adds SSO, SCIM provisioning and unlimited users.
Can contractors report incidents?
Yes. Pilots and Ground Staff both report incidents and risks, so a contractor's crew files them against the job they're on. On Business and above, incident reports can also be anonymous.
Should contractors share one login?
No. A shared contractor account breaks attribution: the audit log shows the account, not the pilot. Give every contractor pilot their own login, scoped to their jobs.
Which platform suits a team that uses contractors?
One that treats a contractor as a member of your team who sees less. In FlybyOps, contractors work in the same roles as your own staff, scoped to the projects and jobs you assign.
See it in action
Bring your drone program onto one record
FlybyOps gives enterprise drone teams a single audit-grade record for projects, flights, equipment, risks and incidents. Start free — 14-day trial, no credit card.
Start free trial