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. Taken on an internal test system, so the address and team name are not the ones you will see. Each grey box marks a screenshot still to come.

Two kinds of group, and the difference is enforced

Team Settings › Groups splits the list under two headings. SYSTEM GROUPS are maintained by CupixWorks — All Groups, Super Admin, Team Admin. CUSTOM GROUPS are the ones your team creates.

The table shows Group Name, Type, Description and Members, with Type as a chip reading System or User Defined.

A system group cannot be renamed or deleted, and the product says so on the page: this group is a system-defined group and you are not allowed to change the title or delete this group. Its membership you can change; its identity you cannot.

Working with one group's members

Selecting a group lists its members with their status, and offers Add Members. That dialog matches people already in the team — enter a name or email address and select a team member from the drop-down list — rather than inviting new ones.

So groups organise people who are already here. Adding somebody to the team is a different action, on the Members page.

Moving and removing

A member's panel shows their name, email with a copy control, status, and the groups they are in, with Remove From Group at the bottom in red.

There is also a Move to Another Group dialog, which names the group they are leaving and asks for the one they are joining. It is a move, not a copy — worth knowing if the person should end up in both.

What a group grants

A group carries a permission level, and its members inherit it. That is the point of a group, and it is not set on this page.

Where the permission is set: when you add a group to a workspace or to a project, you choose the permission level that group has there. Everyone in the group gets that level. Change the level and it changes for all of them; take someone out of the group and they lose the access the group was giving them, unless they also have it in their own right.

Which is why the Members tab shows two kinds of access. Its permission table distinguishes access granted directly to a person from access inherited through a group, so you can see which of the two you are looking at before you try to remove it. Permissions are changed there, under Change Permissions, or where the group was added.

So the division of labour is: this page decides who is in the group; the workspace or project decides what the group can do. Renaming or deleting a group is here. Granting it access is not.

The last-admin guard applies here too

Members and Groups use the same test. After whatever you are about to do, at least one active administrator must remain for that scope — and it does not matter whether they hold it directly or through a group. Emptying the Super Admin group here meets the same guard as demoting the last admin on the Members tab.

What the guard then does depends on the scope. At team level you must name a successor before it will proceed. At workspace and project level it warns you and lets you through.