We've officially broken free from the era of "one-size-fits-all" permissions to bring you an upgraded permissions system. This isn't just an update; it's a total evolution in how you manage your team in Wamly.

Gone are the days of choosing between "too much access" or "not enough." We've handed the keys back to you, empowering administrators to build a workspace that is as agile as it is secure.

This guide is your roadmap to mastering our new toolkit, allowing you to grant, "restrict", and customise permissions with accuracy. Let's dive in!

What Are Permissions?

Permissions represent "actions" on specific areas of the Wamly system, including what you are able to:

• View
• Create
• Edit
• Delete

How Does Wamly Structure Permissions?

Our permissions framework uses five core concepts:

1. Seats
2. Permissions
3. Roles
4. Role Levels (Organisation, Department, Cost Centre etc.)
5. Groups

Don't worry, we'll unpack every detail in the sections ahead. But first, let's get you grounded.

Note: The Wamly legacy roles (System Manager, Rater, and Admin) are migrated upon launch. This ensures that migrating organisations retain exactly their existing access while being mapped into the new permission structure. e.g. Org X had 500 Rater Seats, Org X now has 500 Member seats with rater roles. If Org X had 5 System Managers and 20 Admins, Org X will now have 25 Project Admin Seats with permissions scoped exactly to what each of these seats previously allowed.

Here are the pillars of the new Wamly permission system:

• Permissions are the individual "abilities" or the specific actions (View, Create, Edit, Delete) a user can perform across different areas of Wamly. They're the smallest building block of the system, and every Role, Group, and Role Level is ultimately just a way to bundle and apply these.
• Seats: Your Boundary. Think of Seats as your access level, the foundation of your system permission and exactly what you pay for. Whether it's a Project Admin Seat for full access or a Member Seat for stakeholders, this defines the user's capability.
• Roles: Your Set of Permissions. Roles are bundles of permissions, or "abilities". Instead of assigning individual permissions one by one, Roles allow you to package specific "can-do" abilities into reusable profiles.
• Role Levels: Your Territory. A Role tells us what you can do; a Role Level tells us where you can do it. Whether it's a specific Department or Cost Centre, Role Levels ensure users only operate exactly where they are needed.
• Groups: Your Shortcut. This is where you scale. Instead of manually linking a user to many individual roles, Groups allow you to group multiple Roles and users in one place. Add a user to a Group and, voilà, they are instantly equipped and ready to work.

All the pillars work together to give you and your team unique permissions in the Wamly system. Read more about each in detail in the following sections.

Where Do Permissions Live In Wamly?

Navigate to the newly added Users & Permissions section in your menu bar. You will see three tabs: Users, Groups and Roles.

How Do You Get Permissions?

Permissions are granted in two ways:

• Through the Organisation (Top-Down): Your Organisation Administrators (the users with the most permission-granting authority across the organisation) grant high-level access through Roles or Group memberships. This defines your overall ability across the entire Organisation.
• Through the Project (Ground-Up): A Project Manager gives you the "green light" on specific projects. This is precision access, tailored to exactly where you need to execute.

Before we dive into more details, you need to master the foundation. Let's take a closer look at how Seats set the boundaries of your engine.

Note: Permissions are always additive, meaning there are no "deny" rules. So when granting permissions always start with the minimum requirements and build from that.

Understanding User Seat Types

Wamly uses two distinct client seat types to manage access and collaboration. Each is designed to balance security with functional needs.

1. Project Admin Seat

The Project Admin Seat is the highest level of access available. Users assigned this seat have full system authority and can manage all aspects of the platform.

• Capacity: The number of seats is determined by your pricing plan.
• Ability: Specific abilities are still determined by your Organisation Admin through permissions, making this the ideal choice for HR managers.

2. Member Seat

The Member Seat is a versatile, multi-purpose option designed for users who do not require full project administration access.

These seat types can also be used for users with specialised access or limited visibility.

Common roles include:

• Viewer: Provides "read-only" access to designated areas of the system.
• Rater: Restricts access specifically to the rating and evaluation functionality.
• Marketing: Unlocks the Branding Suite and Template Builder to manage the candidate experience.
• IT: Grants access to the Developer Portal, including SSO configuration, API keys, and Webhooks.
• Billing: Limits access strictly to Billing and Transaction History for financial management.

Capacity & Limits

Member Seats are provided at no extra cost; however, the total number of seats you can assign is determined by your specific pricing plan:

Where Do I View & Assign Seats?

• Navigate to the newly added Users & Permissions section in your menu bar.

• Click on the Users tab.
• The table in the user window holds all your user information including user Names, Roles, Seat and Status.
• To edit an existing seat, locate your user in a row and click on the seat column. A modal will open where you can easily select the new seat type and click Change seat.
• To add a new user Click the Add+ button at the top of the table.
• Fill in the details of your user and click Add User.
• Next manage your new user's permissions and set their Roles, Groups and Seat. Click Add 1 user. You did it!

Adding Users on a Project Level

In the project window there is a newly added Users & Access tab which provides visibility on all users who have access to a specific project.

For total clarity, we've split this into two categories:

• Project Team: These are your active contributors. You've specifically hand-picked these people to drive the project forward.
• Others with Access: These users have "Inherited Access." They can see the project by default due to their higher-level organisational roles.

If someone is missing, Project Managers can now grant users access directly to a specific project without them needing an organisation-level role.

• Click the Add to team + button and select the user or group you want to include.
• Keep in mind that their global seat type will still act as the final boundary for what they can actually do.

How Do User Seats And Permissions Work Together?

In the Wamly system, user seats and permissions work together through the following steps:

1. Organisation admins assign seats to individuals.
   • Remember seats don't grant power; Admins do (via Roles). The seat simply acts as a hard limit on what a user can actually do.
2. When you take an action, the Wamly system bundles your permissions and caps them at your seat level.
3. If a permission exceeds your seat type, you'll see a warning and the action only unlocks once the seat is upgraded.

Well done! You've nailed seats and users. Hopefully your coffee is strong, because roles are where things get really interesting.

Exploring Roles

In the Wamly system, if permissions are the building blocks and seats are the boundaries, roles, role levels and groups are the delivery systems that make managing access scalable. Administrators now have total command to create, edit, and delete roles.

How Do Roles & Role Levels Work Together?

• A role is a named, reusable permission set.
• Instead of assigning individual permissions one by one, you can bundle them and give your users a role with preset permissions. Cool, right?
• View the roles table to see the role name, role level and permission access.
  • e.g. An HR Manager role tied to an organisation role level with full view, edit, create and delete access.
• Every role is permanently tied to a specific "role level" (Organisation, Department, Cost Centre, Project, or Stage) as seen in the first column of the roles table.
• However, because changing a role level would silently break existing access, a role's level is locked and cannot be changed after it is created. To change the role level you need to create a new role with a new role level.

How To Create A New Role?

Admins can create a role by navigating to the Users & Permissions window and clicking on the Roles Tab and then Create +.

• A modal will appear. Fill in the role name, description and role level and toggle individual permissions (here listed by product area) on or off for granular access.
• A summary count at the top of the table shows how many permissions are active per area.
• Click Save, and the role becomes immediately available for assignment.

How To Assign Roles In Projects?

Project managers can add project roles and even bulk assign roles to their users in the Users & Access tab while working in a project. Simply click on the Add to team + button. This triggers the normal Add user workflow.

Project managers can also add stage roles and allocate permissions to their project team based on stages. The next section describes this permission in more detail.

Exploring Stage Permissions

A Stage is simply a step in your hiring journey, like Screening, Interview, or Offer, that candidates move through as they progress. With the new permissions system, each stage can have its own access rules, so you decide exactly who gets to see and work with candidates at every point in the process.

Open the Stages tab while setting up your project. At the top, next to Application Stages, click Manage to add new stages, remove ones you don't need, and drag them into the right order.

Just below, the Application Stages section is where the magic happens. You can view Automatic Assignment and Stage Permissions here.

Automatic Assignment works the same way it worked before to assign raters automatically. The Automatic Assignment permissions give you limited control over permissions through the use of access modifiers.

Stage roles can also be added in this view. Click Add members + to bring a team member in, then choose what additional role they should have at each stage. The moment a candidate moves to the next stage, their access adjusts automatically depending on their Stage Permission (e.g. allowing a specific team member to run background checks on candidates in a specific stage).

Want to give the same role to a whole group of people in one go? Use the Bulk assign dropdown at the top of any stage to apply it across everyone at once.

You're still here? Bravo! You've conquered roles and stage permissions. Next up: Groups.

How Do Groups Work?

Groups are simply collections of roles. Their purpose is to save you the tedious work of managing roles for users one by one. Let's break it down:

• You assign a role directly to the group itself and all the users who are added to the group automatically gain access to the same role permissions. Think of it like a shortcut.
• You can also stack roles within a group. Everyone in this Departmental group X must be able to view transaction history (Billing), create skills tests (Templates) and edit stages (Projects).
• Therefore a single group can hold multiple different roles across different role levels.
• Because permissions are additive, a user can belong to a group and also have another role assigned directly to them (or inherited from a second group) that gives them extra permissions.

Creating a Group & Assigning Access

While in the Users & Permissions window:

• Click on the Groups tab and click Create +.
• Give your group a clear name (like "Cape Town HR Team") and a description.
• Now add users. Search and select existing users to add them to the group. If someone isn't in the system yet, you can click the "+" button to invite them on the spot without losing your progress.
• Note: This will require you to allocate a seat to said user.
• Allocate one or multiple roles to your Group by selecting preset roles, with their corresponding role levels, from the dropdown menu.

You can even preview permissions to see the big picture describing what this group can view, edit, create and delete.

Key Rules to Remember:

• Organisation roles apply everywhere automatically and will not have a predefined role level.
• As soon as a user is added to a group, they dynamically inherit all the roles assigned to that group. If a user moves to a different team and is removed from a group, they immediately lose the permissions sourced from that group.

View Activity History

Yes, we track it all. The View Activity History function is your Users, Groups and Roles audit log and acts as a permanent, unchangeable record of every update made to permissions across the platform. It tracks the "who, what, and when" of every change, showing exactly what a setting looked like before and after an edit, so there is always a clear history to look back on.

You can find these logs right where the work happens, like inside a specific user's profile or a project's settings, but you'll only see the history for items you already have permission to view. Because the log is designed to be a "forever" record, entries are never deleted or hidden, even if a user or group is removed from the system, ensuring your organisation always has a reliable trail for troubleshooting or compliance.

For your IT team: Service Accounts

Got integrations? Meet your new best friend.

A Service Account is a non-human identity built specifically for integrations and API clients that need to talk to Wamly on behalf of your organisation. Think of it as a dedicated "robot user" - it has a name, it has permissions, and every action it takes is tracked, but it can't log in, has no password, and never takes up a seat on your plan.

How Do Service Accounts Work?

If you give your IT-person a member seat with developer permissions, now would be a good time to hand this over to him or her.

Service accounts live in the Users & Permissions area under a dedicated Service Accounts tab, completely separate from your regular users list. They won't appear in seat allocation screens, group membership lists, or bulk user operations.

Each service account has:

• A name — something descriptive like "ATS Sync" or "Reporting Pipeline"
• An optional description so your team knows what it's for.
• One or more API tokens, the keys your integration uses to authenticate.

Permissions are assigned using the exact same role model as regular users. Just pick a scope and a role, and you're done. The one exception: service accounts cannot be added to groups, their permissions come from direct role assignments only.

Managing API Tokens

Again, if you are still reading this, teamwork makes the dream work - call IT. From the service account detail view, you can create, label, and revoke tokens at any time. A few important things to know:

• Token values are only shown once at creation — copy and store them safely. If a token is lost, revoke it and create a new one.
• Each token has a label, a created date, and a last-used date so you always know what's active.
• Revoking a token immediately invalidates it — there's no grace period.
• A single service account can have multiple tokens (handy for separate staging and production environments).

Seats & Billing

Service accounts are not counted against your seat quota. They don't consume an enforced seat allocation and won't affect your billing.

Audit Trail

Every API action performed by a service account is attributed to it by name in the audit log, so instead of seeing a user email, you'll see something like "ATS Sync". If a service account is ever deleted, its audit entries are retained as "[deleted: ATS Sync]" so your history stays complete.

Wow! We know that this is a lot. The Wamly devs now need a vacation and if you are still reading this, you do too.

To help you better understand permissions our Account Management and Support teams are standing by to get you up to speed. Contact your designated Account Manager or email your query to support@wamly.io.

Terminology