Roles and permissions

Variation in the scope of visibility

Opero makes available only the areas you have access to. This is not a fault or an accident: the system deliberately limits the view so that everyone works on their own data and does not browse data outside their scope.

In practice this means a colleague's screen from another department may look completely different. Different menu entries, different lists, sometimes different buttons on the same form. Before you conclude that something is broken, check whether the cause is not the access scope.

The role says what you may do

Permissions follow from the role granted by the administrator. A role is not a description of a position, but the scope of what is allowed in the system. The names are sometimes tailored to the company, but the meaning is usually similar.

One person may have a different scope at different levels: one in the whole organization and another in a specific company. That is why it happens that in one company you change something and in another only view it. This is intended, not an inconsistency of the system.

A role is not the same as a task assignment. A role says what is allowed in the system. An assignment in a process says that a specific matter awaits the user. You may have broad permissions and zero tasks, or the reverse: narrow access and a task to do.

Three reasons you do not see something

When you look for an area that was mentioned and it is not there, the cause is usually one of three.

1. You do not have permission to this data. The most common reason. The area exists, but not for the given role.
2. You are in another company. The data belongs to a specific company. Switch the company context and check again.
3. This area is not shared with the given company. A module may work in one company and not be enabled in another.

Example. "I do not have the contract list, but Marek does." Three questions in order: are we in the same company, do we have the same role, is the module enabled in both companies. One of them almost always explains the difference.

Hiding versus lack of access

It is worth knowing this difference, because it saves misunderstandings. The menu organizes work, but is not a safeguard. If an entry is missing from the menu, it does not automatically mean the data is closed to you, and if an entry is visible, it does not mean you will get into everything behind it.

The scope of visible data is decided by permissions, not by the menu layout.

Requesting access

A request for access is resolved in a minute when it contains specifics, and drags on for days when it is general. Write the administrator three things:

• What you need access to: the name of the area or a specific record.
• In which company, if you work across several.
• For what purpose, that is, what you are to do: only view, enter data, or approve.

The last point is more important than it seems. Read access and change access are two different decisions, and the administrator prefers to grant exactly as much as is needed.

Example. Instead of "give me access to projects", write "I need to view the projects in the Trade company to check deadlines for the clients I handle". The second version settles the matter without further questions.

The record of user actions

A user's actions stay in the system: at a record you can see who created it and who changed it. This is a normal part of teamwork, not surveillance. Thanks to it, for "where did this change come from" the answer is in the record's history, not in guesswork.

If you see a change made by the system or an automation, it means a rule or an integration acted. It too is described in the history.

Related

Working across companies describes switching the company context. Change history describes the record of authorship of changes. Menu describes the layout of entries that organizes work. Assignments and approvals describe tasks directed to specific people.