Rolling out now. Roles and capabilities are being switched on organization by organization. If yours has not been switched over yet, you will still see the older Admin, Staff and capability checkboxes — that way of working is being retired as the rollout completes.
Every membership in 360Player carries a role, and that role decides what the person can see and do in that group. A role is a named bundle of capabilities, and each capability has levels — so "can look at payments" and "can issue invoices" are two rungs of one setting rather than two unrelated switches.
What a role is made of
Role type — Player, Staff or Admin. The type sets the starting capabilities and decides whether the role reaches into subgroups.
Title — what the role is called in your organization: Coach, Treasurer, Team manager.
Description — optional. It shows as a hover on the roles list, so it is the place to record why the role exists.
Capabilities — the individual permissions, listed in groups by product area.
Capability levels
A capability is not simply on or off. Each one is a short ladder, and the rungs are cumulative — granting a higher rung grants everything below it.
Off — no access.
Read only — can see it.
Read and write — can see it and change it.
Admin — can also manage records that belong to other people.
Not every capability offers every rung. Exporting members is read-only, commenting on an event is write-only, and only a handful — events, videos, group posts, player development, activity — go all the way to Admin.
Because the rungs are cumulative, a lower level cannot be switched off while a higher one is on. Switch off the highest level and the one below it takes over.
Role types and where they start
Player — participation. Sees their group, its calendar and posts, the training library, their own development records, and can comment on events.
Staff — read and write across the areas a coach or team lead works in: calendar, games and statistics, training, video, player development, group posts.
Admin — everything Staff has, plus the organization itself: members, groups, roles, payments, forms, scheduling and settings.
A fourth type, Owner, holds every capability and exists at the top of the organization. Owner roles cannot be created and Owner is not offered in the role editor.
Whatever type you start from, the capabilities are yours to change. A Player-type role can be granted write access, and an Admin-type role can have capabilities taken away.
Three things called "default"
The word turns up in three different places, and they are not the same thing.
1. The roles you start with. Every organization is created with one role per type, named Player, Staff, Admin and Owner. These are sometimes called the default roles, but there is nothing special about them beyond being there first: they are ordinary roles, and you can rename them, change their capabilities or delete them once something else covers the type.
2. The Default label on the roles list. This is the one that has a real effect. Each type has exactly one role carrying the label, and that is the role a person is given when they are added to a group and nobody picks a role for them — a registration form, an import, a bulk add to a team. Change what the labelled role grants and you change what every future member of that type starts with.
Because there is exactly one per type, Set as default moves the label rather than adding a second one. The role that had it loses it. A role carrying the label cannot be deleted until another role takes it over.
3. "The role default" on a person's capability screen. When you adjust capabilities for one person, the level their role grants is the default for that row, and Revert puts the row back to it. It has nothing to do with the Default label — it just means "whatever this person's role says".
How access travels through your groups
A role sits on one membership, in one group. What happens in the groups below it depends on the type.
Staff and Admin roles reach down. Whatever the role grants in a group, it grants in every group beneath it, however deep. An Admin in Academy is an Admin in Girls and in G15.
Player roles do not. A Player-type role applies only in the group it is attached to.
This is why organization-wide work — payments, registration forms, roles themselves — is done from a membership in the top-level group.
Legal guardians follow their child's memberships, but only where the child's role is Player-type. A guardian never inherits a Staff or Admin role.
Adjusting access for one person
You can give one person more or less than their role grants, on a single membership — see Change a person's role or capabilities. Anything set that way applies only in the group where you set it — it does not reach into subgroups the way the role itself does. When the extra access has to cover a whole branch of the organization, put the person on a role that grants it, attached at the top of that branch.
Where roles are managed
Open the top-level group of your organization and go to Settings > Roles. The entry only appears if you hold the Roles capability yourself. That is also where you build new ones — see Create a custom role.
Roles is the capability that unlocks the others. Anyone with Read and write on Roles can grant any capability to anyone, including themselves. Keep it to the people who are meant to decide access.
If you do not see Settings > Roles
Roles are being switched on organization by organization. Until yours is switched over, access is set with the older capability checkboxes on each user — see Assign capabilities to an admin or staff member. Nothing is lost in the switch: admins and staff keep the access they already had.