On this page

• Eight grades on three levels
  • What each grade is
  • What each grade can do in capture and SiteView
• Team roles
  • Super Admin is shown, never offered
  • Admins reach downward without being listed
• Workspace roles
  • Membership arrives from projects
• Project roles
  • A Project Admin can open Team Settings
• Rules that apply at every level
  • Each level has its own vocabulary
  • What changing a permission compares against
  • Nobody can leave a level without an administrator
  • Removing and deactivating are different
  • How access is refused

Eight grades on three levels

CupixWorks gives access at three levels, and each level has its own grades. A grade held at a level reaches everything underneath it.

Guest exists only on a project, and it is the one grade whose reach is set app by app. It has its own article: Guests - one grade, access set per app.

All three levels are managed in one place, Team Settings › Members. The Permission Scope tree on the left picks the level: All Members for the team, then each workspace, then each project inside it. The columns in the table change with the level you pick.

1. Permission Scope picks the level: All Members, a workspace, or a project inside it.
2. Roles & Permissions shows the grades for the level you picked.

What each grade is

The descriptions in quotes are the words CupixWorks prints on the Permission Levels card, on a workspace's Workspace Members tab and a project's Members tab. If this table and your screen ever disagree, the screen is right.

What each grade can do in capture and SiteView

This applies to every project, whatever else it has switched on. The four admin grades share one row: inside their own level they have the same access, and differ only in how far that level reaches. Guest has two rows because a guest's access is set per app.

• All - every SiteView in the project. Shared only - only the SiteViews a Project Admin has shared with them.
• View only - sees what others made, cannot create or change it. Create & View - creates their own and sees everyone's.
• ? - not confirmed yet, deliberately not guessed.
• Capture means recording in CupixCapture or uploading through CupixConnect. A Read Only guest can take a temporary measurement but cannot save it.

The add-on apps (CupixConnect, Drone Capture, AssetAtlas, SiteInsights, DeltaBIM) each have their own table in Permission matrix - what each role can and cannot do.

Team roles

At team level the table shows Super Admin, Admin and Member.

Super Admin is shown, never offered

You cannot grant Super Admin. It is displayed wherever someone holds it, and it appears in no dropdown: not in the invite dialog and not in Change Permissions. A grade that can be handed out would not be the top of the tree, so Super Admin moves only by transfer.

Admins reach downward without being listed

A Team Admin or Super Admin can open every project below them without appearing on that project's member list. The project's roster is not everyone who can see the project. Keep that in mind when you audit access.

Workspace roles

At workspace level the table shows Workspace Admin and Workspace Member. Someone whose access comes from the team shows the team's name as a chip in these columns instead of a tick.

1. The two workspace grades.
2. Access inherited from the team shows the team's name instead of a tick.

Membership arrives from projects

Adding someone to a project makes them a member of that project's workspace. Nobody adds them to the workspace; the membership follows from the project assignment. If someone appears in a workspace you never invited them to, look at the projects inside it.

It does not work in reverse:

• Ending a project assignment does not end the workspace membership. They stay in the workspace until somebody removes them there.
• Removing someone from the team removes everything below it: their workspace and project memberships go with it.

Project roles

At project level the table shows Project Admin, Project Member, SiteView Member and Guest.

• Project Admin manages the project: its members, its setup (BIM, levels, SiteViews) and its add-on apps.
• Project Member opens every SiteView in the project, views the add-on reports, and can add captures.
• Guest is covered in its own article.

The same descriptions appear on the project's own Configuration › Members tab. That tab does not list members itself; its Manage Members is the way in to project-level access. See Configuration - the project's own settings.

1. Permission Levels describes the project grades.
2. Manage Members opens Team Settings › Members with this project already picked.

A Project Admin can open Team Settings

One guard covers the whole Team Settings shell, and it admits Super Admin, Team Admin, Workspace Admin and Project Admin. So the highest grade on a single project can open the team's settings.

Today the shell lists eight sections, in this order:

1. General
2. Members
3. Groups
4. License
5. Standards
6. Templates
7. Asset Categories
8. Trash

What someone can change inside each section still follows their grade. License, for example, needs Team Admin.

Rules that apply at every level

Each level has its own vocabulary

A team grade is not a workspace grade under another name. There is no rule that a team Super Admin equals a workspace Admin.

A person whose access is inherited shows the source level as a chip in the table (the team's name at workspace level, the workspace's name at project level) instead of a tick. Opening Change Permissions for them offers only the grades of the level you are on, and today marks the inherited grade as Current.

What changing a permission compares against

Change Permissions compares against the permission held at the level you are changing, not the team-level one. Where someone holds a grade directly at this level, that option is selected and carries a Current badge.

Which level you are changing is decided by where you opened the dialog. A workspace and a project can carry the same name, so the name in the header is not enough to tell you.

At project level the dialog offers Project Admin, Project Member and Guest. Save stays unavailable until you pick a grade different from the current one.

Nobody can leave a level without an administrator

Removing, deactivating or demoting the last administrator of a level is not refused; it is interrupted. A Transfer Admin dialog asks you to name a successor, then promotes the successor and completes your action in one step.

• Demotion counts. Super Admin down to Admin goes through the same rule when it would empty the seat.
• Promotion and removal are one action, so there is never a moment with no administrator.
• Cancel abandons your original action too. Not naming a successor is not agreement to go ahead anyway.

With two administrators present, removing one is an ordinary removal.

Removing and deactivating are different

• Remove takes the person off the level.
• Deactivate keeps their record and their permissions and suspends their access. Reactivating returns it.

Both ask for confirmation, and removal is shown as the destructive one. A deactivated member stays in the table with their permissions shown, because the table answers how permissions are distributed, not who can act today.

How access is refused

Where someone does not hold the permission for a section, its sidebar entry is not shown to them. If they reach the address directly, they get a screen naming the role that is required.

Two places in the product do not follow that rule yet, and both are logged as defects rather than described as behaviour:

• Team Settings redirects silently instead of explaining.
• The Guest screen offers a Request Access dialog.