How FactoryOS Decides Who Sees What
Most systems split access control into two separate mechanisms: one decides which pages a person can open, the other decides which data they can see. FactoryOS uses a single engine for both. The same three-tier cascade that decides whether someone can open the Workflow editor also decides whether their assistant can see the HR channel — and the same screen configures the two side by side.
One Engine, Two Surfaces
The permission engine governs two things at once. Features are the pages, tools, and capabilities a person can use — the Workflow editor, the personal assistant, Persona Studio, the prompts library, the dashboard widgets, the ability to manage other users. Channels are the partitions of data the brain can see for that person — the shared company channel, project-scoped channels, the user's own private channel.
The permissions screen places these as two tabs — Permissions and Channels — and the same cascade resolves both. That matters because feature access and data access are usually entangled in messy ways. Splitting them into separate tabs but resolving them with the same logic keeps both explicit.
How a Decision Gets Made
A permission decision walks three layers, top to bottom:
1. User override. A setting placed on this individual person, if one's been set. 2. Their role. The role they belong to — default or custom — if it has an opinion on this permission. 3. System default. The baseline that ships with FactoryOS.
At each layer the answer is one of three states: allow, deny, or inherit. The first layer with an allow or deny wins, and the cascade stops there. Layers that say inherit defer to the next layer down.
A user with no personal overrides falls through to their role; a role with no opinion on a specific permission falls through to the system default. That keeps individual customization light — most people get the role they're given, and the role does the work — while still allowing exceptions when one is warranted.
Seven Bedrock Roles
FactoryOS ships with seven roles that cover most organizations out of the box:
- Owner — Immutable, the top of the chain, typically the CEO/Founder. - System Admin — the IT-side role, manages users and system settings. - Executive — the C-level leadership tier. - Manager — the middle-management tier. - Member — the typical operational employee. - HR Officer — handles the people side of the business. - Auditor — read-only oversight.
Custom roles can be added on top — "sales floor," "contractor," "intern" — each starting from a permissions baseline you set, and individual users can then override specific permissions on top of whatever role they belong to.
Why Channels Never Bleed
The brain's data is partitioned into channels. The company-wide channel holds shared knowledge — policies, organization-wide announcements, the structure of the company. Project channels hold work scoped to specific clients, deals, or initiatives. Each person also has a private personal channel that nobody else can see.
Channel (data) access flows through the same cascade as features. Default roles get default channel access; custom roles get whatever channel set you defined for them; individual users can be granted or denied specific channels on top of that. The HR channel doesn't bleed into operations chat because operations roles don't have HR-channel access — and the cascade makes that not a checkbox someone could forget to tick, but the baseline behavior.
The personal channel is the strictest case. Nothing at the role layer can reach it; nothing at the system-default layer can reach it. Only the user themselves sees it, and the [assistant attached to them](how-your-personal-assistant-stays-yours).
Every Page Can Be Gated
The granularity is per-feature. The permissions UI groups capabilities by area — Administration, AI, Dashboard, Tools, Assistant — and inside each area, individual pages and capabilities are independently controllable. The Workflow editor, the Manifold tool, Persona Studio access, the personal-assistant chat in the header, the prompts library, the activity heatmap on the dashboard, the ability to manage other users' permissions — each is its own toggleable line in the matrix, set independently per role and per user.
The same matrix flips the view between By Role and By User. By Role shows what a role can do across every feature; By User shows what a specific person can do after their personal overrides resolve on top of their role. Both views read off the same underlying cascade. All from one simple interface.
That's the brag. There isn't a feature in the system that can't be turned off for a role or a person, there isn't a channel that can't be walled off the same way, and the answer to "can this user do this?" is always one of the three states with a single source you can trace back through the layers.