Responsibilities enable you to control what permission users have when accessing a program (much like how security clearance levels work). Just because you have access to a program does not mean that you should have permission to make whatever changes you see fit — this is where responsibilities come in, by restricting who can make changes, add new data, and delete data.
Responsibility levels are assigned per
The easiest way to remember the distinction is the think of the responsibility level of a User Group as a key () and the responsibility requirement of a program as a lock ().
User responsibility level
A responsibility level is associated with each user when they are assigned a
User Group. When a user opens a program this responsibility level is compared against the responsibility requirements of the program to determine what permissions to grant them (if any).
|The responsibility level of a user only needs to be the same or greater than the responsibility requirement being accessed.|
Let’s look at an example where responsibility levels can be applied before diving into the details of responsibility requirements and permissions.
One way to setup access controls within Avanti is to allow any user group to access all modules. (The
Canadian Payroll module may be accessible to all members of the Payroll, Managers, and Administrator user groups for example.)
However, this presents a bit of a problem when we have employees who only need access to certain parts of the
Canadian Payroll module to perform their jobs. We might only want
Payroll Processing to be accessible to employees and restrict certain sensitive programs like the
Employee Profile to only those in management for example.
Luckily this is exactly the type of thing that responsibilities enable us to do. By assigning a high responsibility requirement for the
Employee Profile and a low responsibility requirement for
Payroll Processing we could prevent any users with a low responsibility level from accessing anything except the Payroll Processing program.
Users with the lowest responsibility levels will still have access to
However, no other programs will be accessible without a higher responsibility level.
Multiple user group memberships
Users only have a single responsibility level that is derived from all their user group memberships. When a user has membership in more than one user group, the highest responsibility level is chosen for the user.
The user Jane is a member of both the Payroll and Management user groups with responsibility levels
A respectively. Jane will have a responsibility level of
A (the highest).
Previously, we have glossed over what the responsibility levels are. The levels are identified by a single letter (
A being ranked the highest and
Z being ranked the lowest.
|User responsibility levels are more permissive as they increase and more restrictive as they decrease. With program responsibility requirements the opposite is true: they are more permissive as the requirement decreases and more restrictive as it increases.|
When a user has a responsibility level of
Ait will be more permissive than a lower level: giving access to all responsibility requirements ranked the same or lower.
When a program has a responsibility level requirement of
Ait will be
more restrictivethan a lower level: users must have the highest responsibility level in order to meet this requirement.
Similarly, a responsibility level of
Zon a user will be most restrictive and a responsibility requirement of
Zon a program will be most permissive.
|Additional levels like |
Program responsibility requirements can be assigned to programs, sub-functions, and reports. Requirements are assigned to one or more permission types that determine what a user can do when accessing the program.
Responsibility permissions are separated between four kinds of access:
Delete — each of which can be assigned a separate responsibility requirement.
Insertpermission allows you to add new items to a program.
(For example, adding a new employee would require this permission).
Modifypermission allows you to change existing items in a program.
(Updating an entry on an employee’s profile would require this permission.)
Viewpermission allows you to view items in a program.
(This permission is required for all other types of access.)
Deletepermission allows you to remove items in a program.
(This would be required to remove an employee.)
|These four permissions work together: you would require permission to view something before you could modify it for example.|
One common use for responsibility is to restrict who can change data while allowing anyone to view data in a program.
For example, the
Employee Profile could be made view-only for some users, while restricting permission to delete, insert, and modify to only users with a responsibility level of
Deletepermissions are assigned a responsibility requirement of
Viewpermission is assigned a lower requirement of
|Users with responsibility levels of |
Responsibility requirements and User Group access
When thinking about responsibility requirements it can be tempting to think of them as requiring User Group access, but this is not actually the case.
Responsibility requirements are broader than User Group access and simply require that a user has a high enough responsibility level to receive certain permissions.
As briefly touched on previously, the responsibility level of a user comes from their membership in a
User Group. The responsibility level of a user will be the highest level of all user group memberships they are part of (not just those listed in the User Group access or the program).
|In practice User Group access has no effect on responsibility and applies after.|
This is confusing at first so let’s look at this situation in more detail in the following example.
Let’s look at an example of how a user’s responsibility requirement is determined in a situation where they have multiple User Group memberships with different responsibility levels. The program in this situation has a user group access restriction placed on it but we will show that the responsibility level is independent of the allowed user groups.
The menu item has a responsibility requirement of
Cthat will prevent anyone with a responsibility level lower from viewing it.
Additionally, User Group access is used to restrict the menu item to members of the selected user groups.
This user has membership in two user groups: one of which can access the program (SUMMITUSER) and the other can not (MANAGER).
The user group that is not allowed to access the program has a responsibility level of
The group that does have permission to access the program only has responsibility level
Your first instinct might be to think that the user will not be able to access the program because the user group which can access the program has a lower responsibility level than the program requires. However, with this setup the user will be able to access the program. This is important and its worth taking a moment to think about why this happens.
This works because responsibility requirements are above user group access. So long as the user has a high enough responsibility level (which can come from any user group they are a member of) they will pass the responsibility requirement.
|If the user was not a member of one of the User Groups given access to the program then of course they would not have been able to access the program at all. It is important to note that this happens after the responsibility requirement.|
User Groups and programs can use unrestricted responsibility levels to effectively by bass the responsibility requirement.
Users with membership in a User Group with an unrestricted responsibility level will be able to access programs with any responsibility requirement.
Programs with an unrestricted responsibility requirement can be accessed by users with any responsibility levels.
Programs are unrestricted so that any user can access them by using the wildcard
*in place of a responsibility requirement.
User Groups can also be given unrestricted responsibility levels using the wildcard