The Roles and Permissions module gives schools a powerful and flexible way to manage staff access. This new setup allows for granular permissions, ready-to-use role templates, and role assignments at multiple levels, all designed to match the responsibilities of your staff. Read this article to learn all about this module.
This article will cover:
Overview of Roles and Permissions
Role definitions at Account, Programme and Class level
Configuring Roles and Permissions
Understanding role precedence
Overview of Roles and permissions
Let’s first understand what roles and permissions mean in Toddle:
Permissions: These are specific actions users can be allowed or restricted from doing, such as creating unit plans, accessing the admin portal, or editing progress reports.
Roles: A role is a bundle of permissions. One role can be assigned to multiple users and updated centrally. When you update a role’s permissions, the changes automatically apply to all users assigned to that role.
Roles are defined at three levels - account, programme and class. A user’s role determines their permissions within each of these three contexts.
For example, a user can be a basic user at the account level, a principal at the programme level and a teacher at the class level. A role is mandatory at the account level for all users. If no role is defined at the programme or class level, the account-level role will apply in those contexts.
Let’s now understand what each role entails and how roles can be configured in Toddle.
Role definitions at Account, Programme and Class level
To access the Roles and permissions module, navigate to the ‘Admin portal’ and click on the ‘Role and permissions’ card under ‘School-wide configurations’.
This section acts as your school’s central hub for managing staff access based on their responsibilities and level of involvement.
On the landing page, you will see three tabs: Account roles, Programme roles, and Class roles. Each tab contains predefined role templates at the corresponding level and shows how many staff members are currently mapped to each role.
Let’s understand the pre-defined roles at the 3 levels.
1. Account roles
Account-level roles define what staff member can do across the entire school. These roles are particularly relevant for non-teaching staff or administrators who require access to school-wide configurations and insights. Let’s look at what each role entails:
Super admin
This is the highest-access role in the system. Super admins can configure every aspect of the account, including school setup, managing the roster, enabling modules, and assigning other super admins. This role is typically assigned to platform administrators or school leadership who require complete access.
Account supervisor
This role provides view access to all classes and most account-level modules, such as attendance, planning, and insights. This is well suited for school heads, coordinators, or academic leaders who require oversight without needing to make changes to the setup.
IT admin
This role is focused on data and user management. It allows users to manage staff, students, family members, classes, and subjects, and also trigger syncs with the school’s Student Information System (SIS). This role is ideal for IT leads or administrative staff responsible for rostering and maintaining school data.
Basic account user
This role has no permissions at the account level. Users with this role cannot access any school-wide configurations. This is typically suited for classroom teachers who perform their tasks entirely within the programme or class context.
2. Programme roles
Programme-level roles control what a staff member can do within a specific curriculum programme. These roles are for users who have responsibilities within a specific programme in the school, such as programme principals, curriculum coordinators, grade level coordinators, heads of department, etc. Let’s look at what each role means:
💡Permissions assigned at the programme level apply to all classes in that programme unless overridden by a more specific class-level role.
Programme admin
Staff members with this role can manage all configurations for the programme, including academic setup, calendars, and more. They also have access to view all classes within the programme, even if they are not directly assigned to them. This role is ideal for programme coordinators or curriculum leaders who manage programme-wide operations.
Programme principal
This role offers view-only access to all classes and most programme-level modules such as attendance, planning, behaviour, and insights. It’s well suited for school leadership who need visibility into how a programme is running without needing to make changes to its setup.
Teacher
Users assigned this role can access and work on their own classes within the programme. They can view announcements, school policies and resources, manage calendar events, and access the school library. They can also create incidents for students and suggest evidence for authorization and evaluation cycles. This is the default role for most subject or class teachers.
Communications manager
This role allows staff members to manage announcements and messaging for the programme. It is typically assigned to staff responsible for coordinating internal communication across a specific programme.
Attendance manager
This role provides access to attendance-related configurations and insights within the programme. It is suitable for staff members who need to monitor and manage attendance trends at the programme level, without needing access to individual class-level details.
3. Class roles
Class-level roles control what a user can do inside specific classrooms. These roles are perfect for assigning access to teachers, assistants, or support staff based on how they work within a class. Let’s go over what each class role means:
Class teacher
This role provides full edit access to all features of the classes they are assigned to. Class teachers can create and manage unit plans, assignments, portfolios, attendance, announcements, and more. This is typically used for class teachers, subject teachers, or anyone responsible for leading instruction in the class.
Observer
Observers have view-only access to all areas of the classes they are assigned to. They can browse lesson plans, student work, and progress, but cannot make any edits. This role is ideal for mentors or shadow teachers who need visibility into classroom activities without being involved in day-to-day teaching.
Teaching assistant
Users with this role can grade assignments, manage weekly planners assigned to them, mark attendance, and view all other features of the class. They support the main class teacher and have access to perform only selected instructional or administrative actions. This role is designed for support teachers working alongside lead teachers.
Substitute teacher
This role is for staff who temporarily takes over a class in the absence of the main teacher. They can mark attendance and view all other class content, but have limited edit access. The permissions can be adjusted based on your school’s preferences to control what substitutes can or can’t do while covering a class.
Now that you have understood the definition of pre-defined roles, let’s see how you can configure them to suit your school's needs.
Configuring role permissions
Once you have a clear understanding of the responsibilities associated with each role, you can easily access and manage them from the respective role tabs.
Use the three-dot menu against a role to edit the role’s description. Additionally, to view or configure the specific permissions of a role, click the arrow ( > ) at the end of the row.
💡Note that you can’t delete any roles or edit the role description for the Super admins.
As you enter a specific role, you will see a detailed permissions panel. The structure of this panel varies based on the level of the role you're editing:
For account-level roles, you will see permissions grouped by all three levels: Account, Programme, and Class, since these roles span the entire school setup.
For programme-level roles, you’ll only see Programme and Class level permissions. Since they don’t manage the broader school setup, account-level permissions are excluded from view.
💡Permissions assigned at the programme level apply to all classes in that programme unless overridden by a more specific class-level role.
For class-level roles, you will see only class-level permissions, as these roles are meant for educators and support staff who work within specific classes only.
Additionally, you will see that for each account level, permissions are organised under modules such as Admin portal, School roster, Announcements, etc. Each module contains granular permissions, specific actions a user is allowed or restricted from performing.
Each module has a toggle switch to enable or disable access to that entire module for the role. Turning off the toggle disables all the related permissions within that module.
Some permissions are marked with a ‘P’ icon, indicating a power permission. These should be approached with caution and enabled only when absolutely necessary. For example, the ‘Manage school roster’ permission allows users to make significant changes to the school's data and structure.
You may also see a link icon beside certain permissions. This means the permission depends on another related permission to work properly. Hovering over the icon will show you which permission is linked. For example, to enable access to sync and integrations, the user must have access to the Admin Portal.
💡These indicators are consistent across all roles and levels and are designed to help you make informed decisions while configuring permissions.
Additionally, you can apply the ‘Permissions’ filter at the top right to display all permissions or restrict the view to those enabled for the selected role. You can scroll through the list or use the left navigation to jump between sections.
Click ‘Edit’ to enter editing mode.
From here, you can:
Enable or disable a full module using the toggle switch on the right. Disabling a module automatically disables all associated permissions. Toggling it back does not restore previously selected checkboxes; you’ll need to manually re-enable individual permissions.
When a module is enabled, select or deselect individual permissions using the checkboxes next to them. For example, you can allow a user to view announcements but restrict them from creating and publishing them. If a permission is greyed out or disabled, it’s usually because the entire module toggle is off or it’s dependent on another permission.
💡The ‘Edit’ button for the Super admin account role will be disabled as it cannot be edited. However, you can configure permissions for the other roles to tailor access based on your school’s needs.
When you configure role permissions, you may notice some modules or permissions showing an ‘N/A’ label instead of a toggle or checkbox. It means that the permission cannot be controlled or edited at the level you are currently viewing. Granting or denying access to such modules must be done through the user’s account-level role instead.
For example, the ‘Announcements’ module appears under programme permissions but shows N/A. Even if you enable related permissions like ‘Create and publish announcements’ here, it will not grant access unless the user's account-level role also has access to the Announcements module.
When you’re done, click Save changes to apply the updated configuration.
Now that you have a better understanding of configuring role permissions, let's look at how Toddle decides which role’s permissions apply when a user is assigned multiple roles across account, programme, and class levels.
Understanding role precedence
When a user is assigned roles at multiple levels (account, programme, and class), Toddle uses a precedence system to determine which role’s permissions should apply in a given context. This system ensures that the most specific role always takes priority over broader ones.
Let’s walk through an example of how roles are assigned to a staff member and how role precedence works using a staff member.
Ari Nolan is assigned the following roles:
Class teacher in 1A
Substitute teacher in 1B
PYP Programme admin at the programme level
Account supervisor at the account level
Now, when Ari navigates Toddle, the platform checks for the most specific role available in that context and applies it using the precedence logic — Class > Programme > Account.
In 1A, Ari is explicitly assigned as a Class teacher. Since class-level roles have the highest precedence, Ari gets full edit access to everything in this class, regardless of any roles at the programme or account level.
In 1B, Ari is assigned the Substitute teacher role. This again is a class-level role, so even though Ari is a PYP Programme admin, the more specific class-level role overrides it. Ari sees limited access based on how the Substitute teacher role is configured.
In other PYP classes where Ari is not assigned a class-level role (e.g., 2A), the platform checks the next role. Since Ari is a PYP Programme admin, those permissions apply. Ari can access all PYP classes in a view-only mode unless otherwise configured, and manage programme-wide settings like evaluations, calendars, or reporting.
Outside the PYP programme (e.g., MYP or DP), where Ari doesn’t hold any class or programme-level role, her Account supervisor role applies. This role gives Ari view access to all classes across MYP and DP, along with key modules like attendance, insights, and planning.
This ensures your staff always have the right access in the right places, with clearly defined roles and permissions tailored to their responsibilities.
We hope that you could find what you were looking for. Explore other articles for more!