In a network of locations, access usually grows on its own: a shared “Administrator” login at the counter, the cash register password in the work chat, a location manager who signs in under someone else's account because “it's faster”. While there is one location, this looks like a trifle. When there are ten locations and employees move between them, it becomes a matter of money and trust. We go through how to set up roles and access so that everyone sees what is theirs — and so that it doesn't cost the manager an hour a day.
why a shared login for the shift is a security hole
A shared account for the shift seems convenient: no need to set anyone up, a newcomer sits down at the counter and works. The price of this convenience becomes visible later.
- You can't see who did what. The discount was given by “Administrator”, the order was cancelled by “Administrator”. Who exactly — is worked out from the shift schedule and from memory.
- You can't measure a person. A technician's output, an administrator's intakes, mistakes — all of it is tied to a person. Under a shared login there is no person.
- You can't restrict anything. If the account has access to the location's reports, everyone who knows the password has it — including a trainee on the first day.
- The dismissed employee stays inside. A password the whole shift knew isn't changed after a dismissal: it would have to be handed out to everyone again.
- Passwords live in chats. “Send me the login” is the most frequent message in a work chat, and it stays there for years.
principle one: one person, one account
The basis of order is that every employee has their own account. Not one per system, but one for everything: in ID.Knopka one account opens CRM, ERP and LMS. An employee signs in by an SMS code or a password — and from then on, in any product, they are the same person.
This matters more than it seems. When an employee has three logins in three systems, the manager sets them up three times, and on dismissal has to remember three times where to close them. When there is one account, a person appears in the network once: their intakes in the CRM, their output in the ERP and their courses in the LMS belong to one account.
principle two: a role belongs to a location, not to a person
In a network people rarely work strictly at one location. A location manager runs their own location and covers for a colleague at a neighboring one. A technician takes shifts in two places. A franchise partner owns three locations.
If a role is tied to the person as a whole — “Olga is a location manager” — then she is a manager everywhere, even though at the neighboring location she only comes in as an administrator to cover. That is why in ID.Knopka a role is set at a location: at one location a person is the location manager, at another an administrator. The account and password stay the same, and at each location they see what their role there allows.
who should see what
The set of roles is different in every network, but the logic is the same: a person sees what they need for their work and nothing extra. Here is how roles usually fall out in a service network:
| role | what they need for work | what is usually extra |
|---|---|---|
| front-desk administrator, intake clerk | order intake and pickup, the location's clients, the shift's cash, chat with clients | location profit, colleagues' pay, other locations |
| technician | their own items in progress, statuses, their own output, their own courses | the whole client base, the location's money |
| location manager | everything for their location: orders, cash, team, technician pay, inventory, team training | other locations in the network |
| partner, franchisee | their locations in full: money, profit for the month, the team and its progress | other partners' locations |
| head office, network owner | the whole network: analytics by location, royalties, training of all teams | — |
The table is a guide, not a law. The main rule is the minimum necessary access: it is easier to widen a role when a person really lacks data than to find out later who exported the client base.
how an employee gets into the system
The most vulnerable point of any access scheme is the moment a new person arrives. If it takes writing to support, calling the owner or waiting until Monday, a shared login “until they're set up” will reappear at the counter.
In ID.Knopka the manager sets up a newcomer with an invitation link:
- the location manager sends the employee an invitation link with the right role;
- the employee registers through the link and signs in by an SMS code or a password;
- they immediately land in their location with the right role — in all products: they take orders in the CRM, see their output in the ERP, take courses in the LMS.
No calls to support and no password passed through a chat. How to make sure a newcomer not only gets access in the first week but also learns the standard — in the article training a team in a service network.
transfers and dismissals
Access breaks not at intake but at exit. An employee moved to another location — and the old role stayed. Left the company — and the account is still alive because it was forgotten in one of three systems.
When there is one account and roles are set by location, all this is done in one place: remove the role at the old location, grant it at the new one, close access for the person who left. No need to go round CRM, ERP and LMS in turn. And the history of their work — orders, output, completed courses — stays in the system: it is tied to the person, not to a password that was changed.
one directory of locations for all products
A role at a location makes sense only if “location” means the same thing everywhere. If in the CRM a location is called “Center”, in accounting “the mall on Lenin Street”, and in training it doesn't exist at all, the reports diverge before the first number gets into them.
That is why ID.Knopka has a single directory: locations, cities, time zones and currencies are set up once, and all products take them from there. For a network in several countries this is no trifle: the location's time zone decides which day a late order belongs to, and the currency decides how the location's money is counted. How a lost time zone breaks reports we covered in the article migrating from another CRM.
activity log: who changed what
Even with perfect roles there will be questions: who granted access, who changed a role, when an employee was transferred. The ID dashboard has an activity log — it shows who changed what. This removes most of the “I didn't touch anything” conversations: look not at memory but at the log.
access in a franchise: a partner sees their own
In a franchise, access also becomes a question of trust between companies. A franchise partner wants to be sure their clients and money aren't visible to the neighboring partner. The head office wants to see the whole network: how locations work, how much they earn, how team training is going.
Roles by location solve this without separate systems for each partner. A franchisee gets a role at their locations — and sees them in full: orders, cash, profit for the month, their team and its training progress. The head office sees the network. A partner's employee sees their own work at their own location. Everyone works in the same products, but each within their own boundaries.
There is a reverse benefit too: when a partner opens a new location, there is no need to build accounting and access for it from scratch. The location is added to the directory, the team is invited by links — and the location works in the same systems as the whole network. More about what a network needs before selling a franchise — in the article how to turn a business into a franchise.
typical mistakes
- Giving everyone full access “just in case”. It saves five minutes during setup and creates a risk for years: the client base and the location's money become visible to everyone.
- Creating one “employee” role for everybody. An administrator and a technician do different work — and need to see different things.
- Tying a role to a person, not to a location. Then the manager of one location becomes a manager everywhere they have even a single shift.
- Leaving access “until the end of the month”. A dismissed employee should not have access for a single day after leaving.
- Not looking at the activity log. The log is useful not only for investigating incidents: once a month it is worth reviewing who granted which roles.
how to put access in order: a checklist
- Make a list of all the people who currently sign in to your systems, and of all shared accounts. It is usually longer than you expect.
- Remove shared logins. Every person has their own account. If you “can't manage” without a shared login, someone lacks a role — grant it.
- Lay out roles by location. Not “who they are in general” but “who they are at this location”.
- Cut off the extra. Go through the table above: which data a person doesn't need for their work.
- Make the invitation the only way into the system. No passwords in chats.
- Close access on the day of departure. Make it part of the dismissal procedure, not a task “for later”.
- Once a quarter, reconcile the list of people with roles against those who actually work in the network.
frequently asked questions
what if an employee works at two locations?
They have one account and their own role at each location: for example, location manager at one and administrator at the other. They sign in once.
how do I add a new employee?
The manager sends an invitation link. The employee registers through it and immediately lands in their location with the right role — no calls to support.
how does an employee sign in?
By an SMS code sent to their phone number or by a password. One sign-in opens all the knopka products — CRM, ERP and LMS.
can I see who granted access or changed a role?
Yes, the ID dashboard has an activity log: who changed what.
why a shared directory of locations?
So that locations, cities, time zones and currencies are the same in all products. If the directories diverge, the reports diverge too.
