On this page

• One page for every level
  • Three doors, one dialog
• Adding someone
  • Invited, then Active
• Reading a row
  • Groups sit in the same table
  • Finding one person
• Changing a permission
• Removing and deactivating
  • Removal runs downward, not upward
  • What happens to their work
  • The last administrator
• What the table is not

One page for every level

Team Settings › Members is where people are given access, at every level. There is no separate sharing panel in CupixWorks 5.0: giving someone access to a workspace or a project is adding them as a member of it.

The Permission Scope tree on the left picks the level you are working on: All Members for the team, then each workspace, then each project inside it. Every node carries its member count. Choosing a node changes the rows and the columns, because each level has its own grades.

1. Permission Scope picks the level.
2. All / Users / Groups switch between everyone, people only, and groups only.
3. The button names the level you are about to add to. Read it before you type.

The grades themselves are explained in Roles - team, workspace and project grades. This article is about handing them out.

Three doors, one dialog

The same Add Members dialog opens from three places:

• the button on Team Settings › Members, with the level picked in the tree
• Manage Access in a workspace's row menu, or in a project's detail panel
• Manage Members on the Configuration › Members tab of a workspace or a project, which opens this page with that level already picked. For a project, that tab is the way in to project-level access; see Configuration - the project's own settings

Adding someone

The dialog takes one or more email addresses, then a Permission Level chosen from radios with a one-line description each, then an optional Notify people (send an email invitation with an optional message), and Send Invitations.

• Super Admin is never offered. It changes hands only by transfer.
• Guest is offered only on a project. A guest's access is then set app by app; see Guests - one grade, access set per app.
• At project level the field reads Members and groups: a whole group can be given a grade on a project in one step.

Invited, then Active

A new person appears in the table straight away with the status Invited, holding the grade you chose. They become Active once they accept and sign in.

So the member list is a record of intent before it is a record of access. A row that has been Invited for a long time is someone who never accepted, not someone who left.

Reading a row

Every row carries three things:

• Who: name and email, or a group.
• Status: Active, Invited, or deactivated.
• The grade columns, where a tick marks the grade held at this level.

A cell can show a name instead of a tick: the team's name at workspace level, the workspace's name at project level. That access is inherited from the level above. It is not a blank and not an error; it tells you where to go to change it.

Groups sit in the same table

Groups appear beside people because a group holds a grade the same way a person does. The Groups tab shows only them; on a level no group has been given, it reads No groups yet. Groups with access to this scope will appear here. Who is in a group is managed on the Groups page; see Groups - system, custom and vendor.

Finding one person

Beside the tabs, Filter by name or email is the fastest route to one row on a large team. The row menu then offers Filter by this user, which pins the view to that person as you move between levels.

Changing a permission

The row menu offers Change Permissions, Filter by this user, Remove and Deactivate.

Change Permissions opens a dialog naming the person and the level, with one radio per grade of that level and a one-line description of each.

• The grade held directly at this level is selected and carries a Current badge.
• Save stays unavailable until you pick a different grade.
• For someone whose access is inherited, today's build marks the inherited grade Current. Saving grants that grade directly at this level; it does not change what they hold above.

Removing and deactivating

Both ask for confirmation, and Remove is shown as the destructive one.

Removal runs downward, not upward

• Removing someone from the team removes them everywhere below it: their workspaces and their projects.
• Ending one project assignment does not end their workspace membership. It stays until somebody removes it at the workspace.

What happens to their work

It stays, and their name stays on it. Notes, captures and comments made by somebody who is later removed remain in the project, still attributed to them. Nothing is reassigned and nothing is deleted.

The last administrator

Removing, deactivating or demoting the last administrator of a level is not refused; it is interrupted by Transfer Admin, which asks you to name a successor and then does both in one step. The rule is set out in Roles - team, workspace and project grades.

What the table is not

• Not a list of who can see this level. Team Admins, Super Admins and Workspace Admins reach everything below them without appearing on the list. A project with four members listed can be visible to a dozen people.
• Not a list of who can act today. A deactivated member keeps their row and their grade, because the table shows how permission is distributed, not who can sign in.