Delegating safely: team permissions in your academy

Your designer needed to change a button colour, so you sent over the password, because explaining would have taken longer. Three weeks later a course is priced a hundred riyals lower than it should be, and nobody can say who changed it or when. The designer did not necessarily do anything wrong. You opened a door wide enough for everything because you wanted one person to walk through it for one task.

This article is not about whether you trust your team. It is about a management question older than any platform: how you decide what each person may touch, and how you enforce that decision so it does not rest on good intentions. The last third is a plain account of what permissions do not do, however carefully you set them.

A permission describes the job, not the person

What stalls delegation in most small academies is that the owner reads a permission as a judgement. Give a trainer a narrow role and you feel you insulted them; give them everything and you feel generous. Both readings are wrong.

A permission describes the job, not the person. The designer building your pages does not need your revenue figures, and the content editor uploading lessons does not need your learners' phone numbers. Withholding those is not suspicion, it protects them too: someone who cannot reach sensitive data can never be accused of leaking it, and someone who never sees the pricing screen cannot change it by accident and then spend a week defending themselves.

The working version of the rule fits on one line: the smallest permission that completes the job. Any smaller and the work stalls and comes back to you daily; any wider and you lose the ability to know what happened.

Applying that rule starts somewhere unexpected: on paper, not on the settings screen. Write down the tasks you want off your shoulders this month. Not the people, the tasks. "Upload the new course lessons." "Build the campaign page." "Teach the Sunday cohort." "Track attendance." Then ask one question of each: what is the least this task needs to get done? The order matters, because if you start from names you end up granting access in proportion to how much you like someone, which is the one measure that has nothing to do with the work.

Framed that way, most of what you delegated through a shared login turns out to be covered by one specific role:

The task you are delegating	Smallest role that covers it	What stays out of reach
Designing pages, branding and colours	Landing editor	Courses, learners, money
Uploading lessons and structuring content	Course editor	Analytics, money, learner data
Teaching one programme and following its learners	Trainer	Everything not assigned to them
Day-to-day operations and data export	Manager	Almost nothing, which is the point
Owning the academy and the final call	Owner	No limits; not a role you lend out

The last column matters most and is the one nobody reads. A role is defined as much by what it closes as by what it opens, and its real value sits in the line its holder never sees.

Two lines only the people who need them should cross

Inside any academy, two lines deserve more attention than the rest: the money line and the learner data line.

The money line covers prices, sales figures and analytics. The data line covers names, emails, phone numbers and every learner's record. Whoever crosses the first can unsettle your whole pricing in one click. Whoever crosses the second walks out one day carrying the most valuable thing you own.

That is why the course editor role was built to work across all of the academy's content without reaching analytics, money, or the personal data in your learner records. This is not a gap in the role, it is its deliberate edge, and it turns delegating content into an easy decision instead of an all-or-nothing surrender.

Data export stays with the owner and the manager alone, because export is the moment your data leaves the platform and becomes a file on somebody's laptop. Everything after that moment is outside your control, which is reason enough to treat manager as a decision you make twice.

The trainer is a special case: assignment is the permission

The other roles define the kind of work; the trainer role also defines how much of it. A trainer is not handed everything and then asked to stay away from what is not theirs. They see only the courses and sessions assigned to them, and anything unassigned is simply not on their screen.

That small difference is what lets one academy hold several trainers without them bleeding into each other. Each opens their dashboard and finds their own rows: their schedule, their learners, today's grading. Nobody has to agree "not to touch" anything, because it was never on offer. Verbal agreements break on the first stressful day; a boundary enforced by the system does not.

The administrative side effect is pleasant too: adding a trainer to a new programme is a one-line decision, and so is removing them, with no disturbance to the rest of their work.

Offboarding is harder than onboarding

Everyone who thinks about permissions thinks about the day someone joins. Almost nobody thinks about the day they leave, which is when the whole arrangement proves itself or falls apart.

1. Revoke or change the role the hour the work ends, not at the end of the month and not when you remember. The change takes effect immediately, with no password reset and no need to re-brief anyone.
2. Review what was assigned to them in courses and sessions, and reassign it, so no cohort is left without an owner and learners are not the first to notice.
3. If the person leaving is the account holder, transfer ownership before they go, not after. Ownership transfer is available to the owner and the manager and moves the entire academy to its new holder, so a partnership ending does not take control of the business with it.
4. Write down what happened: who held what, when it was revoked, and why. That note is what you will need six months later when somebody asks about an old change.

Notice what those four steps saved you: no password changes, and nobody disrupted except the person concerned, because everyone signs in with their own account. A shared login turns one departure into an event that unsettles the whole team, every time.

What permissions do not do

This is the section a vendor chasing your signature usually skips. We write it because a promise wider than the truth gets discovered on the worst possible day.

• There are five fixed roles, not a permission builder. Owner, manager, course editor, landing editor, trainer. You cannot invent a sixth or tick individual capabilities. Choosing between them is picking from a list, not tailoring to measure.
• A course editor works across all content. You cannot confine one to a single course. Row-level scoping belongs to the trainer role alone, so if you want someone limited to one programme, trainer is the role that does it, not course editor.
• A permission says who is able, not who did it. Recording who changed what and when is the job of the activity log, on the Pro plan at 199 SAR a month. The roles themselves are on every plan, from Basic at 99.
• Revoking access stops what comes next, not what came before. Anyone who downloaded a file while legitimately inside their scope keeps it. Boundaries shrink what can be taken; they do not retrieve what was.
• A role is not a contract. The system enforces the limit; it does not write your agreement about what a collaborator may do with what they saw. For anyone training the staff of an organisation, the signed page and the technical boundary work together, and neither replaces the other.

Four common mistakes

First: handing out manager because it is easier. Manager tends to go to whoever asks the most questions, as a way of ending the questions. But the manager sits close to the owner and holds data export and ownership transfer. It is not a role for reducing interruptions.

Second: postponing roles until the team is big. The right time to set them up is a week before you need them, not after the first incident. The first outside collaborator deserves their own account on day one, not your password.

Third: confusing trainer with course editor. Someone teaching a cohort needs trainer, scoped to their rows. Someone building content for the whole academy needs course editor. Upgrading a trainer to editor because "they will upload a lesson too" quietly deletes the boundary you wanted.

Fourth: leaving an academy owned by someone who has gone. It looks like a detail you can put off, right up until you need a decision only the owner can make. Transfer ownership at handover, not six months later while hunting for an old phone number.

If you want one step to take today: write down everyone who gets into your academy by any route, including your own password. Next to each name write the task they actually perform, then pick the matching role in team and permissions and invite them by email so they sign in as themselves. The payoff does not arrive the day you do it. It arrives the first time something changes and you know who changed it.

If you still work alone, do nothing today. It is enough to know the door is there for the day your first designer arrives.

All five roles, invitations and ownership transfer are on every plan, and you can try them during a 14-day free trial with no card before committing to anything.