Adminitration of areas, projects, calendars

User Modules

Task, project & quality management
Contacts and directories module (CRM)
Web management and automation
Human resources
Products, assets and sales
Finance management
Metrics and Measurements

Technical Modules

Sabre plugin module
Enterprise Architect connector

System Modules

The AyMINE Framework Module
System Management

Let us know what you're looking for

Do you prefer to ask us directly?

Call us +420 605 203 938 (the Czech Republic)

or use this contacts

Adminitration of areas, projects, calendars

Admin rules allow you to define who can work with data in an area fully and who can only work with it in a limited way

[PlaceContent]

What the governance covers

Governance applies not only to business areas, but also to other "data areas" that are derived from the group:

Within your configuration, not all areas may be available.

Area permissions

An area has an administrator, which is always a single user. You also need 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 contents.

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 one? When you use a role, e.g. board member, with a board member change, the new member will see the areas as soon as the new role is assigned to him/her 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

Handlers are individuals who can actively work within the area – creating tasks, sharing information, etc. Handlers should be individuals actively involved in the area's processing. However, they need not be individuals who execute assigned tasks but refrain from creating new ones. (A user can see a task they have been assigned to, even if they are not a handler in the area where the task originated.)

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 the manager assigns someone to a task team, as in the previous case, he can see the complete task (including e.g. attached files) but not the other areas.

Area Administration

The area's complete configuration can be managed by its administrator/owner. The area's settings can also be delegated to the administrator. The administrator (a user with the necessary permissions) can view all areas created in the system and can set:

  • ZpraHandlerscovatele
  • Readers
  • Change the area administrator
  • Object mark in the area (see below)
    The administrator cannot see the content of the area. Even though they can administer the area, they cannot view tasks, information, or anything else. Their permissions do not compromise the protection of information managed within the area.
    Area Administrator is an important role when, for example, an employee who was the administrator/owner of an area leaves the company. Because handlers cannot change area ownership, it is essential for the administrator to transfer the ownership role to a new employee. (Note: If transfer processes are active, the transfer of responsibility can occur automatically. However, this may not always be desirable!)

Administrators prepare areas for various business activities and teams using the system. It is advisable for them to prepare them together with roles and assign areas to team roles.

You may be interested in

Brand patterns

You can define which tags tasks and other objects receive for an area.
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.

See separate chapter for more on managing patterns

Additional links