Duco uses a system of permissions, roles and groups to manage what a user is or is not allowed to do. This page describes how to set-up users and groups of users, per the requirements of your organisation.
Please note that these roles all provide systems wide access in Duco. For process specific roles, please review Process Permissions.
Roles
In Duco, it is possible to grant users different levels of access. For example, you can define groups of users that can:
- add and remove other users
- create and configure new processes
- only run existing processes
Exactly how many groups of users you will need depends on how your organisation is structured and also its size. But before going any further, let's describe these concepts in more detail:
A User is just that, a login that a person can use to access Duco. A user has an email, which doubles as a username, and a password to access Duco. See the page Users for more details.
A Group is a set of users. For example, you can have a group called "London FX team". Groups are very useful, it is usually easier to manage permissions on the basis of groups rather than individual users. See the page Groups for more details.
A Role is associated with one or more tasks that users can do. For example, a user with the "User Administrator" role can add, edit and delete users. A user with the "Process Creator" can create and set-up new processes, etc. In Duco the following roles are available:
System Roles
* In order to 'mark a run as failed' you also need to have the Operator role enabled
System roles specific for Cash Module
|
Account Administrator |
Can add/ remove accounts |
|
Balance Administrator |
Can amend balances for statements within a process |
Development Environments Roles
Only visible to clients using Sandbox and Testing environments.
Global Roles
These permissions are not available by default, as they are only necessary for certain specific governance models. As such, they must be requested by a senior business stakeholder.
|
Global Permissions Administrator |
Where enabled, only users with this role will be able approve or reject permission changes, using a four-eyes permission workflow |
|
Global Permission Viewer |
Can view or modify the permissions Users and Groups have for any individual processes and reference tables |
Note that enabling the Global Permissions Administrator will transition your environment into an Advanced Operational Control model, where four-eyes approval will become a mandatory requirement for any permission changes. Click here to read more about a governance model that incorporates the Global Permissions Administrator role.
With Global Permission Viewer enabled, the User Admin permission will no longer be granted as default to the creator of processes, this will also be true for the Operator role when reference tables are created. This means requests for other users to be granted access to a process or a table will need to be channeled through the individuals with the Global Permission Viewer role.
These two roles can either be enabled separately, or together. Where both roles have been enabled, the Global Permissions Viewer will be able to access any process or reference table. However, any permissioning changes that are made (eg. assigning someone User Admin rights) would then need approved by a Global Permissions Administrator.
Process Permissions
In addition to roles, each individual reconciliation process has its own set of permissions.
The page Process permissions documents process permissions in detail.