CupixWorks 5.0 — this article is still being finished. Screenshots marked to be replaced show the right screens and will be retaken before launch. Taken in a support session, so the top of the screen shows a bar you will not see.
Adding someone
Team Settings › Members, then the button in the top right. Its label tells you the scope you are adding to — Add Member, Add Workspace Member or Add Project Member, depending on what is selected in the Permission Scope tree. Check it before you type.
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.
Choose Guest and a step appears. A Configure App Access checkbox, marked guests only, lets you set Read Only or Read & Write per app before the invitation goes out. It is not there for the other grades, which is why the dialog looks shorter until you pick Guest.
Access is membership — there is no separate sharing
In 4.0 an administrator shared a workspace, a project or a SiteView with people through a Manage Access panel. In 5.0 giving someone access to something is adding them as a member of it, at the scope you want them to reach: the team, one workspace, or one project. The same Add Members dialog does the job at every scope; only the grade radios change — Workspace Admin or Workspace Member at a workspace, Project Admin, Project Member or Guest at a project.
It is reachable from three places that all open the same dialog: the button on Team Settings › Members with the scope selected in the tree; Manage Access in a workspace's row menu or a project's detail panel; and Add Members on the Configuration › Members tab of a workspace or project. Which SiteViews a member can open follows from their grade, not from a per-SiteView share.
Invited, then Active
A new person appears in the member 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.
Removing someone, and the thing removing is not
The row menu offers Remove. Removing takes the person off that scope — the scope selected in the tree, not the whole product.
Removing and deactivating are different. Deactivating keeps the record and the permissions and suspends access; a deactivated member stays in the permission matrix with their grade shown. Removing takes them off the list.
What happens to their work when somebody is removed
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.
Removing somebody from the team removes them everywhere below it — from its workspaces and its projects. Ending one project assignment does not work the other way: their workspace membership stays until somebody removes it there.