Open navigation

Responsibilities

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 User Group and they can be assigned to programs. The latter kind will be referred to as a responsibility requirement to distinguish it from the former kind of responsibility levels.

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.

Example 1. Menu item restrictions using responsibilities

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.

4 1 2019 9 51 15 AM
Figure 1. Canadian Payroll module menu from the point of view of a user with the lowest responsibility level.
  1. Users with the lowest responsibility levels will still have access to Payroll Processing

  2. 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 be more 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 of Z 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.
Example 2. Mixed responsibility requirements for permissions

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.

4 3 2019 10 22 18 AM
  1. The Insert, Modify, and Delete permissions are assigned a responsibility requirement of A.

  2. The View permission is assigned a lower requirement of C.

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.

Example 3. User requirement level from User Group membership

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.

4 1 2019 10 21 59 AM
  1. The menu item has a responsibility requirement of C that will prevent anyone with a responsibility level lower from viewing it.

  2. Additionally, User Group access is used to restrict the menu item to members of the selected user groups.

4 1 2019 10 24 02 AM
  1. This user has membership in two user groups: one of which can access the program (SUMMITUSER) and the other can not (MANAGER).

4 1 2019 10 25 32 AM
  1. The user group that is not allowed to access the program has a responsibility level of B.

4 1 2019 10 26 17 AM
  1. 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.

4 3 2019 8 38 09 AM
Figure 2. A program with unrestricted responsibility.
  1. Programs are unrestricted so that any user can access them by using the wildcard * in place of a responsibility requirement.

4 3 2019 9 00 25 AM
Figure 3. A user group with unrestricted responsibility.
  1. User Groups can also be given unrestricted responsibility levels using the wildcard *.

Did you find it helpful? Yes No

Send feedback
Sorry we couldn't be helpful. Help us improve this article with your feedback.