How access works
There is one access model in Structured AI, and it fits in a sentence:
Everything you make is owned by you. It can be widened to a scope. Widening needs that scope's approver to say yes.
Checklists, workflows, code books, team resources - all the same. Learn it once and you've learned all of them. This page builds it up in order: what a scope is, how widening works, who approves, and where projects differ.
1. Everything starts private
Anything you create is owned by you and visible only to you. A new checklist, a workflow you saved out of a chat, a code book you uploaded, a document you drafted.
That's the default and it's deliberate. You should be able to build something half-finished without your whole firm watching, and without having to remember to hide it.
2. Scopes: your teams, and your organization
A scope is a group you can widen something to. There are two kinds.
Your organization is everyone in your firm. That's the wide one.
A team is the narrower one, and it's the piece people miss. A team is a named group configured for your organization - an office, a discipline, a client account, a market:
Water · Transportation · Fairhaven · Toronto · Mechanical
Teams aren't chosen from a fixed list; they're whatever division your firm actually works by. An org owner assigns them.
You can belong to several. Membership is all-inclusive rather than a hierarchy, because a mechanical engineer in the Toronto office working the Fairhaven account is genuinely in all three, and a checklist that matters to the Fairhaven team should reach them without going to the whole firm.
This is why "shared" has three settings and not two. A firm-wide library and a private draft are both wrong for the checklist that only the water team uses.
When a team is retired
An org owner can remove a team from the organization's list. That retires it rather than erasing it:
- Its team page still opens, marked as retired.
- Nothing new can be shared into it, and it stops being offered as a share target.
- What was already shared with it stays revocable - membership outlives the list entry precisely so somebody can still take those grants back.
Retiring a team is not a way to revoke access in one move. If people should lose what the team gave them, un-share the items.
3. Widening is a request, not a switch
Moving something out of private is a request you start and someone else approves.
Private → Shared with team(s) → Shared with organization
You click "Share with team" or "Share with organization". The approver gets an email and an in-app notification saying you'd like to share it. Visibility changes only when they accept. If it's declined you're told, you can fix whatever the problem was, and request again - nothing is lost by a decline.
The share control on an item you own, showing the three states
What you can see, then, is: yours, plus anything shared organization-wide, plus anything shared with a team you belong to.
Who approves what
This is where scopes and roles meet - the approver is defined by the scope being asked for:
| Widening to | Reviewed by |
|---|---|
| A team | That team's lead(s) - or the org owners, if the team has no lead yet |
| The whole organization | The review pool: org owners, plus any team lead |
A team lead is a member of a team who approves what's shared with it and curates its team page. The role exists only because teams exist; there's no such thing as a lead without a scope to lead.
The org-wide door is a pool rather than one person so a request never waits on a single inbox. Anyone in the pool can act on it, and the trail records who did.
Why approval at all? A shared library is only useful if someone is answerable for what's in it. An org-wide checklist is a statement that this is how the firm reviews. A team page is a curated shelf. Both stop being useful the moment anything can land on them unreviewed.
Every request pends, including your own
If you're a lead and you share something into your own team, it still goes through the queue rather than landing live. That looks like ceremony and isn't: it's the only thing that teaches you the queue exists. A lead who never sees a pending item of their own never learns they're the approver, and then nobody else's request gets looked at either.
Nothing stops you approving your own request. The record simply says who released it.
The same applies to Structured AI staff, for a second reason: an admin has manage rights in every tenant, so without this a book or checklist could be published into your team with no record of anyone at your firm agreeing.
Working your queue
If you're an approver, requests come to you:
- Team requests - on that team's team page; the notification email links straight into it.
- Organization requests - an org-wide queue that appears both on the team page and on the Dashboard. Everyone in the pool sees the same group.
Each pending request opens an evidence panel: the same accept / decline controls whatever kind of thing it is, the item's own evidence in the middle, and the conversation underneath.
Declining is a conversation, not a dead end
A decline needs a note - you can't decline with silence, and the interface doesn't offer it.
That note becomes the first message in a thread on the request. The requester can reply, and a reply reopens the declined request rather than forcing them to start again. Reviewers can answer in turn. So "not like this" stays a conversation about one item instead of a rejection someone has to guess at.
An approver's pending-request queue
4. What the model covers
| Thing | Where it lives |
|---|---|
| Checklists | Checklists & custom checks |
| Workflows | Workflows |
| Revit workflows | Connect Revit |
| Team resources | Teams |
| Building codes | Code Review |
Code books present the same three states through the same controls. Under the hood their lifecycle predates this model - the review step there is called publication and the approver a steward - but you don't have to think about the difference.
5. Roles
Roles answer "what am I allowed to do", which is a different question from "who can see this".
In the organization
| Role | What it means |
|---|---|
| Owner | Runs the organization: invites and removes people, sets roles, grants capabilities, sees the Dashboard, and approves organization-wide shares. |
| Member | The normal role. Works on projects, runs checks, uploads documents and codes, shares their own work by request. |
| External collaborator | For someone outside your firm who needs to work one project - a consultant, a client reviewer. Scoped to what they've been given, and never given ownership. |
Team lead and steward sit alongside these rather than replacing them. A lead is a member who approves for their team. A steward is a member who approves code books into the organization's library. Both are granted per person by an org owner; owners hold both implicitly.
Structured AI staff hold a separate platform-admin role for support. That's not something you assign.
On a project
Projects are the exception to everything above, because a project is shared with named people rather than widened to a scope. Each person gets a role on that project, independent of their organization role:
| Role | Can |
|---|---|
| Owner | Everything, including sharing it onward and deleting it |
| Editor | Run checks, upload, comment, mark up, triage issues, generate outputs |
| Viewer | Read the drawings, findings and outputs; not change them |
Open a project and use Share. A project can also be shared organization-wide, which is the right move for a job everyone should be able to look at.
Once shared, everyone sees the same drawings, findings, comments and outputs, live. Assigning an issue emails the assignee a link straight to the finding, and markups on a sheet are visible to the whole team on that sheet.
6. Who can see private things
Two exceptions to "private means private", stated plainly because you should know:
- Org owners and Structured AI platform admins can view members' private items, read-only. That's the price of being answerable for the account, and it's how an owner can help when someone leaves mid-job.
- Team leads cannot. A lead approves what's offered to their team; they can't browse their members' drafts.
What this page doesn't cover
"Why can't I see this tool?" is usually not an access question at all - it's about what your organization has switched on. See Why can't I see this?.
Adding people to your organization in the first place: Organization members & invites.