Skip to main content

Teams

A team collects members of an organisation under a name.

Teams do not affect access​

Being in a team grants nothing and restricts nothing. Nothing in Yessort's permission checks consults team membership.

What someone can do comes from their role. Where they can do it comes from their site scope. A team is neither.

So a team called "Warehouse supervisors" does not give anyone supervisory access — the people in it have exactly the access their roles and scopes give them, and would have it whether the team existed or not.

What a team is for​

Recording that some people belong together, so that anyone looking can see it. A shift, a department, a site's staff.

That is genuinely useful as a record. It is not a control.

Before you create one​

Ask what you expect it to do.

If the answer involves access — "so this group can approve purchase orders" — a team will not do it. That belongs to a role, and if the existing roles do not fit, what a role grants can be changed.

If the answer is "so we can see who is on the late shift", a team is exactly right.

Not the only thing shaped this way​

Yessort has a few entities that collect things under a label without changing behaviour — customer groups are the other notable one.

The pattern is worth recognising: a grouping you can create, name and populate, whose effect is on people reading the screen rather than on the system.

See create a team.