Accesses and Rights
There are many roles in a modern contact centre including e.g. agents that only handle a specific activity type, multi-skill agents, team leaders and administrators. They all work with different parts of the contact centre and of course, not all of them should be allowed into every section. How does Daktela ensure that each role can do what they need to while keeping them out of where they shouldn’t go?
In Daktela, each agent has a set of accesses and rights assigned to them. If we were to over-simplify, we could state that accesses say where agents can go and rights say what they can do there.
Importantly, a set of accesses and rights can be assigned to any number of agents – when you edit rights and accesses, any changes will apply to all agents that use them. This makes it very easy to manage even large contact centres. Rights and accesses are independent of each other and they are set up separately. They are not usable on their own – they only work when they are allocated to a user.
When you first open the corresponding sections in Daktela, they may look quite complicated, but as you learn more about them and understand what they mean, they become intuitive. Things are more complicated than just “where agents can go and what they can do there” that we mentioned at the beginning, but only a little. Let’s have a closer look.
Accesses define which modules users can go to in the Daktela GUI. Users will only be able to see the modules they have access to in the sidebar – in effect, each agent that uses a different set of accesses might have different items in the main menu.
Accesses also set users’ Create/Read/Update/Delete permissions for items contained in those modules, defining their general ability to work with data stored in each module.
The CRUD permissions for a module are not necessarily linked to access to that particular module. A user may e.g. not have access to the CRM module so they won’t be able to see it in the main menu and access it directly. They can however have read permission for the module. As result, they will see CRM data in activities and in other modules where they do have access, if the data is displayed there. If they have access to e.g. Listings, they will be able to read CRM data there. This way you can disallow your agent to browse all your contacts but let them see the ones relevant to what they are doing.
Rights define what specific items users can see in the modules they have access to. E.g. users that have access to the CRM module need to also have rights to the CRM Database the CRM data is contained in to see the data. This can be used to segment your CRM and control which agents see which contacts. If you have e.g. a set of VIP customers and you only want key account managers to see them, you can store those customers in a separate database and only give rights to it to your KAMs.
When users want to edit an item they have rights and update access to, they can open its details and update it. They may however also need rights to certain things in the item details, e.g. other users. Using rights to other users, you can set up processes such as escalation sequences. By only giving regular agents rights to other agents and their team leader, you can prevent them from escalating a ticket directly to higher management. The team leader would then have rights to their agents as well as management users and be able to pass a ticket on to them to escalate it.
Rights also define which queues agents can log into and how, making the basis of what their contact centre work will be focused on by assigning activities to agents.
The use cases mentioned above are just examples of how you can use accesses and rights to have granular control over what different roles in your contact centre can see and do. There are numerous other combinations that you can set up according to the needs of your individual employees and roles. You can read more about our accesses and rights in our Documentation.