Teams
Blueputto Teams lets admins group members into scoped workspaces for folders and collections, with direct management, active status, and safe cleanup.
Grzegorz
Teams give Blueputto a second access layer below organization-wide roles. Instead of treating every member as part of one flat pool, teams let organizations group the people who should work together around the same folders, collections, and records.
That makes Teams different from broad permission control. Roles and Permissions decide what a person can do. Teams help decide where that person should work.
Manage team membership directly in the table
The Teams page is built as a hands-on management table. In the current implementation, each row lets admins work with a team name, assign members through a multi-select control, toggle the team between active and inactive, and remove the team when it is no longer needed.
This is a Scale feature, and the member picker is intentionally limited to non-owner and non-admin users. Owners and admins stay above the team layer, while teams are reserved for scoped operational access.
That split keeps the model cleaner. Teams represent focused working groups, not top-level administrators.
Teams turn folders and collections into scoped workspaces
Teams become especially useful when they are attached to real content structures. In the current implementation, both Folders and Collections can store assigned team IDs, which turns those records into scoped work areas instead of fully open organization-wide spaces.
That means one group can own a document folder for loans while another group works inside a separate exhibition folder. The same pattern applies on the item side, where collections can be visible only to the teams that should manage those object records.
This is also the clearest difference between teams and roles. A role may allow someone to read or update documents. A team decides which folders or collections that permission should actually apply to.
Cleanup stays safe when the structure changes
Blueputto also treats team cleanup as a structural operation, not only a row deletion. In the current implementation, deleting a team removes its references from team-scoped collections, team-scoped folders, pending invitations that still reference that team, and any stored active team session context.
That matters when organizations restructure. A team can also be made inactive without being deleted, which gives administrators a softer way to phase out a group before they remove it fully.
