Roles and permissions

Every organization role, what it can do, and how roles combine with machine access.

A role is the set of actions a person can take across your whole organization. Every member has exactly one. You pick it when you invite someone, and you change it later on the member directory.

IoTFlows serves the role list, so the roles you see in the role picker come from the platform rather than from your organization. This page documents the four roles in use.

The four roles

Organization Owner. The highest level of authority, and the only role that can pay for IoTFlows or hand the organization to someone else. An Owner can view and edit every machine, board, and integration in the organization, whether or not they were added to it. Every organization has at least one Owner.

Organization Administrator. The same authority as an Owner, minus billing, ownership transfer, and deleting the organization. This is the role that runs the plant day to day: adding machines, tuning calibration, managing people, and wiring up alerts. You can have as many as you need.

Organization Member. The shop-floor role. A Member sees the machines they have access to, classifies downtime, runs jobs, creates work orders, and takes part in chats and boards. A Member cannot change the configuration of the organization or of a machine.

Organization Observer. Read-only. An Observer sees the machines and reports they have been given access to and changes nothing, including downtime classifications.

Which role for an operator?

Give operators Organization Member, not Observer. An Observer cannot classify downtime, and unclassified downtime is what makes a downtime report useless: the hours are recorded, but nothing says whether they were a tool change or a breakdown. See Classify downtime.

You do not need more than one Owner. Owner is the billing and ownership-transfer role, and a second one buys you nothing an Administrator does not already have. Keep one Owner, name a few Administrators, and make everyone else a Member.

What each role can do

Capability	Owner	Administrator	Member	Observer
View machines, reports, and dashboards	Yes	Yes	Yes	Yes
Classify downtime	Yes	Yes	Yes	No
Add, edit, hide, and archive machines	Yes	Yes	No	No
Edit sensor calibration	Yes	Yes	No	No
Create and rename downtime categories	Yes	Yes	No	No
Invite and remove members	Yes	Yes	No	No
Change a member's role	Yes	Yes	No	No
Create a team, and manage a team you own	Yes	Yes	Yes	No
Delete any team	Yes	Yes	No	No
Grant and revoke machine access	Yes	Yes	No	No
Choose who is notified by an alert rule	Yes	Yes	Own notifications only	Own notifications only
Manage chat integrations	Yes	Yes	No	No
Manage webhooks	Yes	Yes	No	No
Edit organization settings: name, handle, shifts, auto-downtime rules	Yes	Yes	No	No
View and pay billing	Yes	No	No	No
Create and edit work orders	Yes	Yes	Yes	No
Create a Scheduler or Maintain board	Yes	Yes	Yes	No
Manage a board's members and settings	Board owner	Board owner	Board owner	Board owner

The last row is not a typo. Managing a board is a board role, so it takes board ownership whatever your organization role is.

Alert rules are the one row that splits rather than switching off. An Owner or Administrator sees a subscriber list per event and sets who in the organization is notified. Everyone else sees three switches for their own email, push, and SMS on that event, and cannot change anyone else's.

Two surfaces check the role id, not the name

Most of the product checks the role by name. Two check the role id, 1 for Owner and 2 for Administrator: Operator Performance, which reads "You are not authorized to view this page." for anyone else, and the Exit Operator View control in the profile menu of an operator station, which is absent for anyone else. A role outside the four above behaves normally everywhere else and is refused on those two.

Roles and machine access

Machine access is a per-person list of the machines someone is allowed to see. It is a restriction layered on top of the role, not a role of its own: the role says what a person can do, machine access says which machines they can do it to.

A member with an empty list sees every machine, which is the default. Grant one machine and that member sees only what is on the list, everywhere: the Assets page, the reports, the machine picker on a new work order. For example, a Member restricted to Haas VF-2 can classify downtime there and cannot see Brother S700X1 at all.

A restriction never adds a permission. Grants live on the member directory and are managed by Owners and Administrators only. See Limit which machines a member can see.

Board roles

Scheduler and Maintain boards carry their own Owner and Member roles on top of the organization role. A board owner manages that board's membership and settings; a board member works on it. Adding someone to a board does not change their organization role, and being an Organization Administrator does not make you the owner of every board.

You do not need to plan board roles up front. The person who creates a board owns it, which is the right answer most of the time. Set up the rest when a board outgrows one owner: Scheduler board members and Maintain board members.

Owner-only actions

Action	Why
Open the billing page, add a card, and pay an invoice	Billing is the Owner's liability. An Administrator gets "Only organization owners can access this page."
Restore a suspended organization	The lockout modal every member sees sends them to billing, and only the Owner can act there. A suspended organization stays blocked until its Owner clears it
Transfer ownership	Ownership is what the platform bills against, so only the current Owner can hand it over
Delete the organization	Irreversible, and it takes every machine, board, and record with it

The practical consequence is worth planning for: if your only Owner leaves the company, nobody left can pay the invoice or clear a suspension. Transfer ownership before they go, or contact IoTFlows.