Project roles, groups, and team access management
Access is granted through two different containers. Groups are global objects maintained by Jira administrators; membership changes are organisation-wide and take effect wherever the group is granted a permission, role or filter share. Project roles are defined per project (default software roles include Administrators, Developers and Users) and are populated in Project settings → People with users or groups. Permissions in a scheme are ideally granted to roles, so moving a person between teams is one role change rather than many permission edits.
Team-managed projects simplify this to two access roles, Administrator and Member, managed under the project's Access tab; you add individual users or groups and the project decides what each role may do. There is no permission scheme to inspect.
Traps: deleting a group silently removes every permission grant, role membership and filter share that referenced it; adding a user to a group that is granted a role grants them that role's permissions; a user cannot be chosen as an assignee unless they hold Assignable User in that project, and a project lead set as default assignee must also be assignable; granting a role to a group is not the same as adding each member individually. When deprovisioning staff, start with group membership review rather than editing schemes.
Rule of thumb: roles for project-specific teams, groups for organisation-wide populations such as all staff, and avoid granting permissions directly to individual users.