Roles & permissions: who sees what in the music school

Why roles come before functions

Permissions should follow roles, not individual people. The teacher sees their students, administration sees the organisation, management sees both. That structure stays stable even when people change.

If permissions are instead assigned individually, every change creates effort – and eventually nobody knows who may do what.

Typical roles in a music school

• Teacher: their own students, assignments, practice entries and material
• Administration: organisation, appointments, billing
• Management: cross-cutting view and decisions

These three roles cover most cases. You only divide more finely where it is really necessary.

The principle of minimal visibility

Each role sees only what it needs for its task. That is not mistrust, but order: fewer visible data means less responsibility and fewer sources of error.

Especially with personal data, minimal visibility also makes legal sense – not everyone has to see everything.

Review roles when new tasks or projects begin

A new project at the music school can change responsibilities. An ensemble may need shared scheduling, while a recital may require additional access to materials. Before it begins, check who will do the work and what information they actually need.

After the project, return access to the usual scope. A temporary task does not automatically justify permanent permissions. A brief close-out check ensures temporary sharing has ended and roles remain clear for regular teaching.

Regulating transitions cleanly

The most common stumbling block is the change: a teacher leaves, a new one arrives. If permissions are tied to roles, the change is a role swap – not a rebuild of permissions.

What the role sees stays; only the person behind it changes.

Define permissions in practical terms

For each role, write down a few concrete questions: can it view student records, edit assignments, manage appointments or invite people? These actions are easier to discuss than an abstract phrase such as “system access”. Start with common workflows and add exceptions only when they arise.

Distinguish between viewing and changing information. Someone may need to see the calendar without being able to delete existing appointments. Clear boundaries reduce accidental changes and show who is responsible for each part of a workflow.

Agree on the role model with the team

Roles should match the work people actually do, not just the organisation chart. Ask teachers and administrators which information they need and where they depend on someone else. This reveals gaps before they create workarounds or private shadow lists.

Record the decision briefly: the role, its required access and who is responsible for changing the model. A short shared explanation helps new team members understand the rules without having to request every permission individually.

Review access when responsibilities change

Roles and responsibilities change. After a staff change or a new task, check whether permissions still fit. Remove access that is no longer needed, and grant new permissions only when their purpose is clear.

A regular review—for example at the start of each term—prevents old access from remaining unnoticed. It does not need to be a major audit. A quick look at active accounts and unusual exceptions can reveal outdated access.

Treat data protection as part of role design

Student information may contain sensitive personal details. Do not share everything with the whole team by default. Check which data each role genuinely needs and align the specific setup with your organisation’s privacy obligations.

Clear permissions do not replace training or legal review. Explain how the team should handle credentials, exports and sharing, and make clear who can answer questions. This combines technical limits with a consistent working practice.

Make permissions understandable in daily work

A role model should be clear enough that staff know whom to ask when a function is missing. Describe permissions through ordinary examples: a teacher assigns a task, administration moves a group, a director updates an organisational rule. Concrete workflows reveal whether access is missing or responsibility should be assigned differently.

If someone handles a task only occasionally, check whether temporary access is enough. Remove it again afterwards so special permissions do not remain indefinitely. A brief overview of exceptions helps keep the model understandable and limited to what is needed.

How MUSIRIS maps roles and permissions

In MUSIRIS access is role-based. Teachers, administration and management each see what is meant for their task – without you maintaining permissions for each person individually.

You can try MUSIRIS for free. For music schools there are adapted solutions – get in touch to clarify the roles for your organisation.