User Modules

The right to inspect is important not only to protect information, but also to make work easier. If a user sees only what they need to see in a system, it is much easier to navigate than if they see areas they have nothing to do with. It is therefore advisable to give people access only where they really need it.
Restricting the right to see is not just a matter of internal interest, it is also a legal obligation. For example, data protection legislation (GDPR) mandates the protection of everyone's personal data. Therefore, all personal data must be placed in the system in such a way that only those users who need to see it because of legitimate interests or a legal obligation, or the data subject has given his/her consent, can actually see it.

Who looks after the areas

The basic areas typically corresponding to the competency and organisational breakdown are set up in the system from the beginning during administration. Additional areas can be created and set up by users as required (not all users are authorised to do so).

Example of use: A manager can create, for example, an area for a new task. For example, a business owner creates an area to prepare a strategy for the next year and only allows access to the area to a few colleagues with whom he is working on the strategy (e.g. top salespeople and the head of product development). In the area, they can share all documents and collaborate regardless of their job title. The information they share in the area will not be seen by anyone else, not even their direct reports. They won't even know that the area exists in the system.
As the example shows, creating areas is a useful tool for managers to structure information and work among "their" people.
In addition to the administrator, there is the area administrator (see below).

How to create an area

An area is created with a button in the list of areas. The area must be filled in minimally:

Name should be telling
Brief description containing a specification of what the area refers to.
In addition, it is highly advisable to fill in:
Status should correspond to reality. Areas that are not active are not offered to members on the dashboard. Therefore, active areas should be those that are actually being actively worked on.
The * Description has mainly a documentary sense, e.g. for archiving content or reports, so that it is clear even years later what activities have been carried out within the area.
Administration tab – permission settings

Area permissions

An area has an administrator, which is always one person. It is also necessary to set a group of people who have the right to actively work in the area (work) and the case of people who do not work in the area, but can view its content.

In both cases these are groups of people (roles). It is possible to select an existing group (for example, all employees, or a specific team or role), or use the Processors / Readers buttons to create a new group.

When to create a new group and when to use an existing group? When you use a role, e.g. Board Member, as the Board Member changes, the new member will see the areas as soon as the new role is assigned in the system. There is no risk that the area administrator (probably the director) will forget to put the new member among the area members. For long-established areas, it is therefore always advisable to use standard groups, or to create a group containing the roles that should belong to it.

For ad-hoc areas created for a specific task, on the other hand, it may be preferable to create a custom list of people. This gives the area manager the assurance that the team will remain the same at all times and that changes in roles within the company will not unexpectedly alter the list of people allowed access.

Area handlers

Processors are people who can actively work in an area – setting up tasks, information, etc. Processors should be people who actively process the area. Conversely, they do not have to be people who perform assigned tasks but do not create new tasks themselves. (A user can see the task he has been given, even if he is not the processor of the area in which the task was created.)

Readers

Readers are typically people who, by virtue of their authority, are supposed to have an overview of what is happening in the field, but do not actively process it. A typical example might be a director, a new incoming manager, an auditor.
Attention: to legislative restrictions. E.g. a company director has the right to see into the accounting area, but because of GDPR they do not have the right to look into the personnel files of employees. He can therefore be a reader in economic areas without restriction, but cannot be a reader in areas with employees' personal files.

Example: The head of the economic department has the area of controlling. The reader in the area is her and her deputy. The director of the company is the reader.

The manager and deputy may create tasks, activities, and other objects in the area of
The director sees into the tasks in the area, their progress and execution. He cannot change anything (but he can, for example, add an alert to a task and send it to the manager)
If the manager gives a task to an invoice clerk within an area, the invoice clerk will see the task among her tasks, she will also see which area it is from, but she cannot see what else is being handled and processed in the area. The assignment of the task does not compromise the protection of the information in the area
If a manager assigns someone to a task team, as in the previous case, they can see the complete task (including e.g. attached files), but cannot see elsewhere in the area.

Area administration

An area can be completely set up by its administrator/owner. It is also possible to leave the setting of areas to the administrator. The administrator (an employee with the necessary permissions) can see all the areas that are created in the system and can set them:

Processors
Readers
Change the area administrator.
Tags of objects in the area (see below)
The administrator cannot see the contents of the area. Although he can administer the area, he cannot see tasks, information or anything else. Therefore, his permissions do not compromise the protection of the information that is administered in the area.
The Area Administrator is an important role when, for example, an employee who was the administrator/owner of an area leaves the company. Since the permissions of an area cannot be changed by the processors, it is necessary for the administrator to transfer the role of owner to the new employee. (Note: If transfer processes are active, the transfer of responsibility can be done automatically. However, this is not always desirable!)

The administrator will prepare areas for the different areas of the company's activities and the teams of people who use the system. It is advisable that he prepares them together with the roles and assigns the areas to the team roles.

Sample tags

It is possible to define for an area what tags are given to tasks and other objects.
For example: The 345th record in January 2020 in the Accounting area can receive a tag:

> 2020-1/Ucetnictvi/345

Only a person with administrator privileges can define tags. If you want custom tagging in your area, you need to agree with him.

Area types – extension support (system note)

Areas are not only used to break down the tasks and activities of the company, but also break down all other business objects that are handled in the company – assets, events, people (and external entities), etc. An area is a general repository that AyMINE also uses for many other purposes: