By Artem Korsakov ·
In short: In an account for a legal entity, the organization and the employee are separated: contracts and order history belong to the company, while the login method and permissions belong to the person. Roles are described through specific actions and visible records. Invitations, deactivation and changes to company details are thought through before launch. Access separation is accepted using test accounts of two companies.
A customer account for a company should take into account employees with different tasks: a procurement specialist, an accountant and a manager. The procurement specialist places requests, the accountant receives documents and the manager oversees the overall work. A shared password makes it hard to know who changed the data and whose access needs to be closed after they leave.
An account for a legal entity is best designed around the organization and individual employees. This does not mean that everyone needs a unique role. It is more important to define a few clear rules and test them on real work situations.
First separate the organization from the person
The company name, contracts and order history belong to the organization. A personal email address, login method and available actions belong to the employee. This separation helps keep documents when the contact person changes. Deleting a user should not automatically destroy the client’s business history.
Before development, decide who confirms a person’s link to the company. Typing the company name into a form does not prove that the visitor has the right to see its orders. You can provide for an invitation by the client’s current administrator or verification by a member of your team. The specific procedure depends on the value and sensitivity of the information. How these decisions affect the budget is covered in the article “How much does a customer account cost”.
A role describes an employee’s actions
The “accountant” role seems clear until an accountant appears who places requests on behalf of a colleague. That is why the actions need to be listed next to the role name:
- viewing invoices;
- downloading completion certificates;
- creating a request;
- inviting employees;
- changing company details.
After that it becomes clear which combinations are really needed.
In a hypothetical service company, the client wants to give an office administrator access only to requests from their own branch. A finance employee should see documents for all branches. These are already two dimensions of access: what a person is allowed to do and which records they can see. They cannot be replaced with a single “regular user” switch.
Do not create a separate role for every rare exception without checking. Sometimes two general roles and a branch restriction are enough. The more combinations there are, the harder it is to explain the system and check the consequences of changing permissions. For external partners, the same questions are covered in the article “A partner account or access to the CRM”.
A document needs an owner and a life cycle
For documents, determine whether they belong to the organization, a request or a contract. Decide when a file becomes available to the client, whether a version can be replaced and whether the previous one needs to be kept. An employee needs to understand which document is current and which piece of work it relates to.
A link from a notification must not bypass access rules. You need to check both the list of documents and the opening of the file itself. Otherwise a hidden row in the account only creates the appearance of a restriction. The method of technical implementation is chosen by the developer, but the testable result should be described in plain words.
Invitations and deactivation are part of the product too
Think through what happens with an unused invitation, a wrong email address and adding a person again. Who is notified about a new employee? Can a company be left without its administrator? These questions become especially noticeable after launch, when support has to fix the situation manually.
When an employee is deactivated, their active access should end according to agreed rules. Their history of actions remains linked to them as the author. Moving a person to another organization requires a separate scenario so that previous documents do not accidentally move along with the profile.
Another useful check concerns changes to company details. Who is entitled to propose a new value, and when does it appear in documents? If changes require review by a manager, the user should see the intermediate state. Automatically replacing data in all old documents can distort the history, so updating the profile and the content of previously issued files are discussed separately.
How to accept access separation
Test procedure:
- Prepare several test accounts for two fictional companies.
- In one company, set up different roles and branches.
- Check the list, search, notifications and directly opening someone else’s record.
- Change the permissions of a user who is already logged in and see how access ends.
Before expanding the set of features, agree on the rules for data ownership and how they are checked. The trike_dev customer account demo will help discuss these scenarios on screens.
Частые вопросы ### Can you manage with one account?
For demonstrating the process this is sometimes convenient, but in a working account with documents a shared login gets in the way of managing responsibility.