The request usually arrives as a technical one. A franchise manager, or a warehouse manager, or a plant manager asks for access to the training system so they can see who on their team has finished what. Head office says yes in principle, then spends four months not deciding what exactly that person may do.
The delay is not incompetence. Underneath the access request sit four organisational questions most groups have never answered explicitly, and software cannot answer them. This guide is about those questions; the tooling is the easy half.
It is framed around franchise managers because the tension is sharpest there, but the need is identical for anyone running one site inside a larger structure. A warehouse manager wants to know who has been instructed on the new racking rule. A production manager wants to know which operators are cleared for Monday's line. A shop manager wants to know whether the four people on Saturday have done the till procedure. Same question, different building.
The law already names the person you are hesitating to trust
Worth raising early, because it turns the conversation from a favour into an obligation.
In Belgium, Codex art. I.2-15 requires the employer to organise the onthaal of every worker and to entrust it to a member of the hierarchical line. Art. I.2-11, second paragraph, 9° goes further: the designated member of the hierarchical line signs, under their own name, a document showing that the necessary information and instructions on welfare at work were given, and an experienced worker is designated to accompany the new starter.
The name on that document is not a training administrator at head office. It is the member of the hierarchical line where the work happens, which in a multi-site group is the site manager. When they ask to see whether their new starter has been instructed, they are not asking for a convenience. They are asking for sight of a duty the Codex placed on them personally.
That does not mean they should be given everything. It does mean the default reverses: the question is not why should this person have access, but what would justify withholding it.
Four questions worth settling before anyone gets an account
Separate them deliberately. Organisations that treat them as one end up with either a site manager who can do nothing or one who can quietly rewrite a central procedure.
Who may see? Whose completion records, whose knowledge check results, whose history, across what boundary. The cheap one, and the one most often over-restricted.
Who may assign? Whether a site manager can put an existing course in front of one of their people with a deadline, or has to request it centrally.
Who may create? Whether they can write something themselves, and if so whether it stays local or enters the shared library.
Who may change what exists? Specifically, what happens when a site manager thinks a central instruction is wrong.
Answer them in that order. Each is a bigger grant than the last, and the fourth is not really a permissions question at all.
Seeing costs less than people expect
Site managers are routinely handed a monthly PDF instead of a view, on grounds rarely examined.
The usual objection is comparison: give a manager sight of other sites and they will benchmark and argue. The more common outcome is worse, which is that a manager who sees nothing assumes their site is fine. The safer boundary is not to hide the data but to limit the population: full visibility of the people they are responsible for, and the network only in aggregate if at all.
The second objection is privacy, and it deserves more respect. Training records are personal data, and a manager who can see completion for people who do not report to them has access they cannot justify. That argues for scoping the view to the reporting line, not for withholding it. Scope tightly, then be generous inside the scope.
What a site manager needs is small and stable: who is behind, on what, by when, and who is new and therefore not yet cleared for anything. A view showing those four, on a phone, replaces the weekly status email, and head office stops being the middleman on data it was only forwarding.
Assigning is where delegation becomes real
Viewing changes nothing on the floor. Assigning does, and it is where most groups stall.
The case for it is timing. A site manager knows on Tuesday that somebody moves to a different machine on Thursday. If assigning the instruction needs a request to head office, it happens after the change or not at all. Codex art. I.2-21 names a change of function and new work equipment as triggers for training, and those moments are visible at the site and invisible centrally.
The case against is not really about assignment. It is a fear that a manager assigns the wrong thing, or nothing. Both are supervisory problems with a supervisory answer: assignments are visible upward. Arbowet art. 8 lid 4 makes supervision of compliance with instructions an employer duty in its own right, so head office watching what sites assign is not micromanagement but the discharge of a separate obligation.
Grant assignment from the central library. Keep the library itself out of reach.
Creating is the boundary that needs an explicit rule
Here the answer genuinely differs by organisation. The mistake is leaving it implicit.
Sites have real local content: the layout of this building, the evacuation route from this floor, the machine on this line, the client whose rules apply at this address. None of it belongs centrally, and forbidding sites to produce it means it gets produced anyway, as a laminated sheet nobody at head office sees.
The workable rule: local content may be created, stays local, and never enters the shared library by default. If something local is good enough to generalise, promoting it is a deliberate act by whoever owns the library, not a side effect of somebody pressing save. That asymmetry, easy to create locally and hard to publish centrally, is what keeps a library from becoming a shared drive within a year.
When a site manager says a central instruction is wrong
This is the fourth question, and it is the one people try to answer with permissions. It cannot be.
A site manager who believes a central procedure does not fit their building is usually right about the building and often wrong about the procedure. The instruction may exist for a reason nobody explained: a regulator, a client contract, an insurance condition, an incident at a site they have never seen. If the permission model lets them edit it, the reason disappears with the text, silently, at one site, where nobody is looking.
If it does not let them edit it and there is no route to challenge it either, something worse happens. The site follows a house version informally, the central text stays intact and wrong, and the gap between written and done grows until an audit or an incident finds it.
So the answer is a process, and none of its three parts is technical. A named owner for every central procedure, so there is somebody to raise it with. A route with a stated response time, because a challenge that gets no answer in a fortnight teaches the site to stop raising things. And an interim rule: while the challenge is open the central version stands, unless the site manager judges it unsafe, in which case they stop the activity and escalate the same day.
Groups that run this find the volume of challenges much lower than feared and the ones that arrive worth reading. Groups that do not discover their house versions during an audit.
Where the platform comes in
Two short notes on tooling, short because the organisational design above is the harder and more durable half.
If a platform supports scoped access, a site manager can be given a view limited to their own people plus permission to assign from the central library without the ability to edit it. If it supports local content that stays out of the shared library, the create rule above can be enforced rather than merely agreed. Whether a given platform does both, and how cleanly, is a question to put to a vendor directly and to see demonstrated rather than described.
What makes the delegation useful in Aristotl regardless is the record underneath it: completion, knowledge check results and version per person, per site and per role, exportable, and readable on a phone, which matters because a site manager has no more of a desk than their team does.
Map it on your own org chart first
Before looking at software, take one site and write down answers to the four questions above for the person who runs it. Bring that to a demo. The conversation about what a platform should enforce is short once the conversation about who decides what has happened.