---
title: "Roles and permissions"
description: "The four IoTFlows organization roles and what each one can do. Organization Owner is the billing and ownership role, Organization Administrator runs day-to-day administration, Organization Member does the shop-floor work including downtime classification, and Organization Observer is read-only. A role says what someone can do; machine access says which machines they can do it to. Scheduler and Maintain boards carry their own Owner and Member roles on top of the organization role."
category: "People and access"
source_url: "https://www.iotflows.com/docs/admin/roles-reference/"
---
# 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](/docs/admin/invite-members/), and you change it later on the [member directory](/docs/admin/manage-members/).

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.

> **Info:**
> **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](/docs/monitoring/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](/docs/monitoring/classify-downtime/) | Yes | Yes | Yes | No |
| [Add, edit, hide, and archive machines](/docs/monitoring/add-an-asset/) | Yes | Yes | No | No |
| [Edit sensor calibration](/docs/hardware/calibrate-senseai/) | Yes | Yes | No | No |
| Create and rename downtime categories | Yes | Yes | No | No |
| [Invite and remove members](/docs/admin/invite-members/) | Yes | Yes | No | No |
| [Change a member's role](/docs/admin/manage-members/) | 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](/docs/admin/machine-access/) | Yes | Yes | No | No |
| [Choose who is notified by an alert rule](/docs/alerts/asset-event-rules/) | Yes | Yes | Own notifications only | Own notifications only |
| [Manage chat integrations](/docs/alerts/chat-integrations/) | Yes | Yes | No | No |
| [Manage webhooks](/docs/alerts/webhooks/) | Yes | Yes | No | No |
| Edit organization settings: name, handle, [shifts](/docs/admin/shifts-and-timezone/), [auto-downtime rules](/docs/monitoring/auto-downtime-rules/) | Yes | Yes | No | No |
| [View and pay billing](/docs/admin/billing/) | Yes | No | No | No |
| [Create and edit work orders](/docs/maintain/create-a-work-order/) | 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](#boards), 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.

> **Warning:**
> **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](/docs/monitoring/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](/docs/monitoring/operator-stations/), 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](/docs/admin/machine-access/).

## 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](/docs/production/scheduler-members/) and [Maintain board members](/docs/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](/docs/admin/suspended-account/) | 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](/docs/admin/manage-members/) | 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](/docs/get-started/get-support/).

## See also
- [Change roles and remove members](/docs/admin/manage-members/)
- [Limit which machines a member can see](/docs/admin/machine-access/)
- [Maintain board members](/docs/maintain/board-members/)
- [Scheduler board members](/docs/production/scheduler-members/)