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 programs in a section. (Canadian Payroll
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 Canadian Payroll
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
Payroll Processing
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 C
and A
respectively. Jane will have a responsibility level of A
(the highest).
Responsibility levels
Previously, we have glossed over what the responsibility levels are. The levels are identified by a single letter (A
through Z
) with 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
A
it 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
A
it will bemore restrictive
than a lower level: users must have the highest responsibility level in order to meet this requirement.Similarly, a responsibility level of
Z
on a user will be most restrictive and a responsibility requirement ofZ
on a program will be most permissive.
Additional levels like B , C , … Y can all be used and behave the same: those level which rank higher are more permissive for users and are more restrictive for programs. |
Responsibility requirements
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
Responsibility permissions are separated between four kinds of access: Insert
, Modify
, View
, and Delete
— each of which can be assigned a separate responsibility requirement.
The
Insert
permission allows you to add new items to a program.
(For example, adding a new employee would require this permission).The
Modify
permission allows you to change existing items in a program.
(Updating an entry on an employee’s profile would require this permission.)The
View
permission allows you to view items in a program.
(This permission is required for all other types of access.)The
Delete
permission 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 A
.
The
Insert
,Modify
, andDelete
permissions are assigned a responsibility requirement ofA
.The
View
permission is assigned a lower requirement ofC
.
Users with responsibility levels of C and B will have view-only access, while A responsibility level users will have all permissions. (If this is confusing just remember that responsibility requirements are the lowest responsibility level needed to be granted that permission.) |
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
C
that 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
B
.
The group that does have permission to access the program only has responsibility level
Z
!
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. |
Unrestricted Responsibility
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
*
.