User Roles: General Information

User roles in MYOB Advanced are sets of access rights to system objects designed for convenient management of access for users with similar responsibilities in the system. In MYOB Advanced, a system object to which access rights can be set up can be a particular form, a container of form elements, a form element, or a wiki.

Tip: For details about managing access to wikis, see Wiki Access Management.

Learning Objectives

In this chapter, you will learn how to do the following:

Create a user role and specify access rights to system objects for this role
Modify access rights to system objects for a copy of an existing role
Give access to only particular forms in the system and revoke access to all other system objects
Review the access rights a role has to system objects

Applicable Scenarios

You create or modify user roles in the following cases:

When you, as an implementation consultant, initially implement MYOB Advanced for your client and the predefined set of roles does not suit your client’s needs
When you, as a system administrator, were notified that the security policy of your company has changed and after a revision of the current set of roles, you need to modify access rights to MYOB Advanced elements
When you, as a system administrator, were notified about a new position being created in your company, for which the current set of roles does not cover the job description

Restriction Levels

A user role in MYOB Advanced is a set of access rights to system objects. By defining access rights for a system object, you set the restriction level a user with the role will have for this object. The restriction level defines the set of operations a user may perform with the object. The highest restriction level allows a user to perform any operation with an object, up to its deletion, and the lowest restriction level denies access to an object.

The system objects are a particular form, a container of form elements, and a form element. In MYOB Advanced, the system objects are grouped in a tree with nodes, where a tenant is the first-level node with the workspaces nested under it. Each workspace can have multiple forms nested, which can have containers of form elements nested within it; form elements are nested within the containers.

MYOB Advanced has the Not Set restriction level, which is specific to the system. The Not Set restriction level indicates that all roles have access to a form, including its nested objects, until at least one role is assigned any other restriction level to this form. All roles with the Not Set level are then denied access to the form. For example, suppose that you have created a new generic inquiry and added it to a workspace. By default, all roles in the system will be assigned the Not Set restriction level to the inquiry. If you assign any other restriction level to at least one role, users that are not assigned this role will not have access to the inquiry.

The set of restriction levels available for the system objects depends on the object type. For some objects, you can specify a more granular level; for others, you can either allow or deny the access. For details, see User Roles: Restriction Level Options.

Access Propagation and Inheritance

In MYOB Advanced, as mentioned, the system objects are grouped in a tree with nodes. Each node is a system object that can nest other objects. At each level of nodes, either access rights are propagated to the nested objects or nested objects inherit access rights from their parents. The hierarchy of nesting is the following:

Tenant: A tenant node nests all workspaces configured in the system. The system propagates the access rights set to a role for this node to all workspaces in the tenant.
Workspace: A workspace node nests all forms added to the workspace. The system propagates the access rights set to a role for this node to all forms within the workspace.
Form: A form node may or may not nest several containers with the form elements. Nested containers inherit the access rights set to a role for a form.
Form container: A container node nests form elements, such as boxes and actions. Nested elements inherit the access rights set to a role for the container.
Form element: An element node is on the lowest level of the object hierarchy and inherits its access rights from its parent container.

Tip: You can observe the tree of system objects in the left pane of forms related to user access configuration, such as Access Rights by Screen (SM201020), Access Rights by Role (SM201025), and Access Rights by User (SM201055).

The propagation and inheritance mechanism saves time for administrators and simplifies the setting of access rights to system objects. You can change the propagated or inherited rights for any object at any time—that is, change the restriction level received from a parent object. For specifics about the restriction levels of a particular system object, see User Roles: Restriction Level Options.

Predefined Roles

For ease of defining and administering roles, MYOB Advanced provides a set of predefined roles, which is expanded with every major release of MYOB Advanced. We recommend that you use the predefined roles while you configure user access to the system during implementation. For details on the available predefined roles, see User Roles: Predefined Roles.

With every major release of MYOB Advanced multiple new forms are added to the system. Depending on the added functionality, any number of new predefined roles can be supplied, which will provide access to the new forms, or access for existing predefined roles can be modified.

If you have modified access rights to a system entity for a predefined role, then the system preserves your changes during the upgrade but updates access rights to other entities for this role, if any were added, deleted, or updated with the new release.

If you have deleted a predefined role, the system will not restore it during the upgrade.

Tip: If a predefined role mostly works for you but needs a bit of tweaking, we strongly recommend copying the role and making needed changes to the copied role.

Role Planning

Organizations have different kinds of valuable information that needs protecting, such as financial documents and customer and vendor information. Different employees need access to different subsets of this information to perform their duties. Before you start planning the set of user roles, we recommend that you make sure that job roles and responsibilities in your company are clearly defined. The job responsibilities of a user define the needed levels of access to forms, records, and operations on the records.

While planning the set of roles, take into account the objectives of internal control procedures implemented in your company, like preventing and detecting fraud, maximizing the completeness and accuracy of financial records, safeguarding assets, and preparing financial statements in a timely manner. For example, to minimize the risk of errors and fraud, duties associated with cash handling are often segregated. Also, segregation is recommended for duties related to recording documents and further processing them, as well as conducting reconciliations and preparing financial statements.

We highly recommend that you perform the planning of access configuration when the system is initially implemented and when there have been changes to the security policy of the organization. For detailed recommendations, see User Roles: Planning of Access Configuration.

Role Creation

You use the User Roles (SM201005) form to create a role. By default, a newly created role has the Not Set restriction level for all system objects. The nested objects (containers and elements) have the Inherited access level.

Tip: We recommend using naming conventions for the user roles that you create or copy from predefined roles.

Because MYOB Advanced is supplied with a set of predefined roles for which access rights have been specified (that is, these roles’ restriction levels to different objects were changed from Not Set to the restriction levels appropriate for each role), a newly created role will be denied access to most system objects.

Important: The Not Set restriction level indicates that all roles have access to a form, including its nested objects, until at least one role is assigned any other restriction level to this form. All roles with the Not Set level are then denied access to the form.

To set up access rights to multiple system objects for multiple roles, you use the Access Rights by Screen (SM201020) form. The form allows you to see the restriction level that other roles have to a system object. This information can be useful when you define the access rights to this object for a particular role because it may affect the access rights of other roles if the Not Set restriction level is specified for them.

To set up access rights to multiple system objects for an individual role, you use the Access Rights by Role (SM201025) form.

Alternatively, you can use the Access Rights by Role form to create a copy of a role, give the copied role a new name, and then modify access rights for the copied role.

Note: The process of defining task-based roles requires in-depth knowledge of both the organization's business processes and the MYOB Advanced approach to security.

Role Access Modification

During ongoing maintenance of MYOB Advanced, you may have tasks to change users' access rights to some system objects. To modify a role’s access you use either the Access Rights by Screen (SM201020) form or the Access Rights by Role (SM201025) form.

You may take different approaches in configuring user access: assigning a single role to a user or assigning a combination of roles to a user. The chosen approach may affect how modification of a role will affect an individual user’s access.

If you do not use role combination, the modification of a role will affect access for all users with the role assigned. If you use role combination, the modification of a role may differently affect users with the role assigned. For details, see User Roles: Calculation of the Restriction Level for a User.

Before proceeding to role modification, we recommend collecting detailed information about the role configuration and the users assigned to the role. For details on access management reports, see User Access: Related Reports and Forms.