Roles and permissions

Every member of an organization holds one role. A role is a checklist of permissions, one or two per area of the product: view (open the area's pages and read its records) and manage (add, change, close or sign). The server checks the checklist on every request, reads and writes alike, so a role is what a person can reach, not what the menu happens to show them.

Organization administrators hold every permission and are not on the checklist. Being an organization admin is a tier, not a role: an organization admin makes someone an admin, or steps a person back to member, with Tier in the Edit user dialog on the Users tab (see Managing your organization). No role, and no identity provider group, makes anybody an organization admin.

The areas#

Only an organization admin or a role with Billing: manage buys anything or places an order; a member without it is refused with a sentence that says so.

Accepting a hazard's residual risk follows your organization's risk policy, not a permission on this checklist: by default any organization admin accepts, and for each band the policy can name any organization admin, a role, named people, or any mix of them. A person or role the policy names accepts without being able to edit the register, as long as their role holds Safety records: view.

The built-in roles#

Eight roles ship with every organization and cannot be edited or deleted; copy one to start a custom role.

• All areas: every permission on the checklist, billing included, except Records custody, which an organization admin gives to a role on purpose. It is not the organization admin tier: the Admin Console, members' accounts, roles and the full export stay with organization admins.
• Member: sees the operation (every view permission except billing, members and Records custody) and files flights and missions; does not manage shared records or read colleagues' records. This is what a member holds when nobody has assigned a role.
• Auditor: reads every area except billing and changes nothing, including the crew board and every pilot's record. Made for an insurer, a regulator, or a customer's quality team: every write is refused. It holds Records custody: view, so it reads the list of packages produced and the legal hold register. The public reporting settings and the full organization export stay with organization admins, and the whole-organization binder with organization admins and roles with Records custody: manage; an Auditor's whole-program audit package carries the binder.
• Pilot: flies and files. Aircraft (view), flights and missions (view and manage), fleet health, maintenance and ops manuals (view). A pilot saves, exports and imports missions, plans sorties and reads the operations manual they fly under. Nothing about jobs, clients or the safety register; a pilot files occurrences and follows their own like any member.
• Maintenance: runs the bench. Aircraft, maintenance (view and manage), fleet health, types, flights and ops manuals (view). A Maintenance member reads the operations manual but does not open the Dispatch board.
• Billing: for a finance or purchasing contact. Billing (view and manage) and nothing else: the plan, orders, invoices and billing details, and buying for the organization, with no aircraft, flights or records. A member holding it sees Billing & plan on My Account.
• Dispatcher: runs the Dispatch board. Aircraft, fleet health, maintenance and ops manuals (view); flights, missions & dispatch, and jobs & clients (view and manage). A dispatcher plans, launches and lands sorties, holds the watch, and opens and edits the jobs the sorties serve. The Crew board and colleagues' records stay a Members: view grant an organization admin makes on purpose; the board itself shows each pilot's standing.
• Operator-maintainer: for a crew member who flies and also does the operator's maintenance. Everything the Pilot holds, plus Operator maintenance (view and manage): a draft maintenance record, adding a component, and fitting and removing parts. Releasing work, deferring and rectifying defects, and changing a part's life limits or status stay with Maintenance: manage.

Custom roles#

On the admin console's Roles card, New role takes a name, a description and the checklist. Tick what the role may see and what it may manage; a manage permission without its view permission is filled in for you, because nobody can manage what they cannot open. The roles table's What it grants column lists each area the role reaches, grouped as "(view and manage)" and "(view)", and under each role's member count the table names the members who hold it.

Assign a role on the Assign a role card: pick the member, and the role picker beside them opens on the role that person holds now, so pressing Assign without changing it keeps their role. No role gives a member exactly what the Member built-in grants. You can also change a member's role with Role in the Edit user dialog on the Users tab, which shows while the person's tier is Member. A member's effective permissions are shown on their row, and the side menu shows only the areas they can reach. My Account shows each person their role by name.

A records custodian#

A records custodian answers records requests and keeps records for as long as they must be kept, without filing or editing any of them. Compose the role from the checklist: for example Records custody: manage, Safety records: view, Flights & logs: view and Members: view. Records custody alone opens the Audit and Retention pages. With it the custodian places and lifts legal holds, sets how long records are kept, produces audit packages and release copies, downloads the whole binder of your own organization, and prints any pilot's logbook. The full organization export, which holds every record and your members' email addresses, stays with organization admins.

A member's records#

A person's own record and logbook are theirs whatever their role, and so is printing their own logbook as a PDF. Printing a colleague's logbook needs Members: view with Flights & logs: view, Maintenance: manage or Records custody: manage. The aircraft, jobs and checklists the logbook offers for filing come with Flights & logs: view, or with the area that holds them (Aircraft & registry: view, Jobs & clients: view). Opening a colleague's page under Crew and the Crew board need Members: view, and seeing the colleague's flights there (where and when they flew) needs Flights & logs: view as well; changing a colleague's details or credentials needs Members: manage; writing the organization's currency rules needs Training programs: manage. A standardization or training officer's custom role with Training programs: manage and Members: manage therefore runs Crew and the rules without being an organization admin. Logging a flight for a colleague is for organization admins and roles that carry both Members: manage and Flights & logs: manage, and correcting or voiding a colleague's flight stays with organization admins; such a role may also name another pilot on File Flights. With Members: view alone, a colleague's page is read-only. A member who names a colleague without the permission is refused, rather than having the save quietly land on their own record. All of it is inside your own organization only.

What every member reads of their own#

Whatever their role, each member opens What I fly under, which shows the authorizations in force, the operations manual revision in force and their own training, as far as their role reaches, and the occurrences they reported on the Occurrences page. Neither widens the role: the whole safety register and every person's training stay with Safety records: view and Training programs: view.

Contractors and external pilots#

A contract pilot is a member. Invite them with the Pilot role (or a custom role that fits the engagement); their flights, currency and credentials are then records of your organization, which is what an insurer or a regulator asks to see. Members are not seats: seats are aircraft. A person who flies for you without an account leaves no record here, and RotorLab does not keep a credential file for someone who is not a member.

Everywhere a role applies#

The same checklist governs every way in: the pages, the Ops Dashboard panels, a member's personal API keys and the MCP tools an assistant can call. A dashboard panel outside a person's role is not offered, and the dashboard says how many were left out. A member's API key reaches only what the member's role sees (reads) or manages (writes), and only the areas the key names, so an Auditor's key cannot file a flight. Under the organization's default key policy only organization admins and roles with Integrations: manage create personal keys, so the built-in Member, Pilot and Auditor roles do not; an organization admin can let every member create keys, or nobody. Organization admins and ground-station device keys are not bound by a role.

What a refusal looks like#

A page a role cannot see is not in the side menu. Each menu row answers to the same permission as the page it opens, so a row a role can see never leads to a refusal: Crew follows Members (view), Dispatch follows Missions & dispatch (view), and Operating Areas follows Safety records (view). A request the role may not make, typed or scripted, is answered with a plain sentence naming the area and the box an administrator ticks on the role: "Your role does not let you see Jobs & clients. Ask an organization admin to tick view under Jobs & clients on your role." An API key or MCP call refused by the role gets the same sentence. Nothing about the refused record is disclosed.

A page that cannot open for you says why, in the words of the answer it got. A role refusal reads Not on your role with that sentence, and never offers an add-on. A page that needs an add-on your organization does not hold names the add-on as the pricing page lists it, with its price. A page an organization admin keeps to themselves says so. If RotorLab itself could not answer, the page says it could not load and offers Reload; it never shows an empty board in place of an error.

What the suite checks#

Every release is checked to confirm that each built-in role reaches exactly what this page says, reads and writes alike.

Related#

• Accounts
• Audit