Project Creation and Processing: Project Security Configuration

Many organizations use projects to achieve their business objectives efficiently. An organization may have multiple projects in progress at a given time. By limiting users' access to and visibility of information about particular projects and related transactions, managers can properly organize the work on each project. In MYOB Advanced, you can use roles to provide access to forms based on employees' responsibilities and restriction groups and to limit the visibility of particular projects to only the responsible team, as described in this topic.

Note: In MYOB Advanced, you can configure groups with direct and inverse restriction. In this topic, for simplicity, groups with direct restriction are used in examples. You can use inverse restriction groups in the same way as you use direct restriction groups. For details on the types of restriction groups, see Types of Restriction Groups.

Usage Scenarios

The most common scenarios of securing projects are the following:

Managing access to particular forms based on users’ roles: Each employee involved with a project has specific tasks. You can define user roles that will give employees access to project-related forms based on their responsibilities. For details, see Access to Forms Based on Roles.
Controlling the visibility of sensitive projects by user: If your organization has multiple project teams and multiple employees have the same functional responsibilities in different projects, you can make particular projects available to employees of only a particular project team by using restriction groups. For more information, see Visibility of Projects by User.
Controlling the visibility of projects by area of the system: If a project should be associated with transactions in a particular functional area of the system (such as accounts payable), you can make the project visible only within this area. For details, see Visibility of Projects by Area.
Managing the visibility of project transactions by account group: If you need to limit the visibility of sensitive project transactions so that only particular users can see and work with these transactions, you can configure access to the project transactions by account group. For details, see Visibility of Project Transactions by Account Group.

Access to Forms Based on Roles

By using the user security forms, you can configure access rights to the project-related forms for each employee, in accordance with the employee's typical responsibilities. For more information about user roles, see User Roles: General Information.

For example, you can create the following roles for employees of your organization who work with projects:

Project Manager: A role for an employee who coordinates projects and is responsible for achieving the project goals. In the system, this person sets up pricing in projects, creates tasks, and configures projects and project templates. This role should have access to project-related forms—that is, the forms in the Projects workspace—including those listed in the Preferences category. Also, this role may require access to the Approvals (EP503010) form so that users with this role can approve projects.
Project Controller: A role for an employee who controls project transactions, performs allocations, and runs project billing. This role should have full access to project-related forms—that is, the forms in the Projects workspace—including those listed in the Processes category.
Project Accountant: A role for an employee who plans and executes the project budget and enters project transactions. This role should have access to project-related forms—that is, the forms in the Projects workspace—including those listed in the Transactions and Profiles categories.
Project Team Member: A role for an employee who works on a project and enters time sheets and time cards. This role should have access to project-related forms—that is, the forms in the Projects workspace—including those listed in the Transactions and Profiles categories. It should also have access to the forms listed in the Time Tracking category of the Time and Expenses workspace.

Visibility of Projects by User

By using the row-level security forms of MYOB Advanced, you can configure the system to hide or display particular projects for employees, in addition to implementing task-based roles. Employees who have access to the Projects (PM301000) form can view or edit all the projects available in your organization. You may need to use restriction groups to restrict the visibility of specific projects to only employees of the project team. For details on restriction groups, see Restriction Groups in MYOB Advanced.

As a simple example, suppose that you need to restrict the visibility of projects to employees in your organization given the following:

There are two projects in your organization: Project Y and Project Z.
User PM is a project manager who controls all projects in your organization.
User AC is an accountant who plans budgets and enters project transactions for all projects in your organization.
Users E1 and E2 are engineers who work on Project Y.
Users E3 and E4 are engineers who work on Project Z.

To configure the visibility of projects according to the listed statements, you would do the following on the Project Access (PM102000) form:

Create two restriction groups of type A (with direct restriction): Group 1 for Project Y and Group 2 for Project Z.
Include the following entities in Group 1: Project Y, and users PM, AC, E1, and E2.
In Group 2, include Project Z, and users PM, AC, E3, and E4.

With the restriction groups you have created, the users’ visibility of projects would be the following:

Users PM and AC can see both Project Y and Project Z.
Users E1 and E2 can see only Project Y.
Users E3 and E4 can see only Project Z.

Visibility of Projects by Area

After you have created a project in MYOB Advanced, the project is available system-wide by default. You can control the visibility of projects within functional areas of the system in the following ways:

Display or hide the Project and Project Task boxes and columns on forms: If you want to track project-related data in particular functional areas (for example, accounts receivable and purchase orders), you can configure the system to display the boxes and columns where a user can specify the project-related data only within these areas. To do this, in the Visibility Settings section of the Projects Preferences (PM101000) form, you select the check boxes for the areas where these elements should be displayed and clear the check boxes for the areas where the elements should not be displayed.
Display or hide a project: If the project transactions of a particular project should be performed within a particular area (for example, inventory), you can make the project visible in this area and hidden in other areas, so that users can select only appropriate projects when they are preparing documents. You can select areas in the Visibility Settings section of the General Info tab on the Projects (PM301000) form. After you have selected an area, users can select the project in documents generated on the related forms, and the release of these documents automatically updates the project data.
Display or hide the tasks of a project: If the users perform particular tasks of a project in a certain area (for example, the Warehouse operations task requires users to enter inventory transactions, and the Customer payments task requires users to enter accounts receivable documents), you can select the areas where the task will be displayed in the settings of the project task. You select these areas in the Visibility Settings section of the General Info tab on the Project Tasks (PM302000) form.

Visibility of Project Transactions by Account Group

By using the Project Transaction Visibility by Account Group (PM103000) form, you can configure the system to hide particular lines of project transactions that contain sensitive information by configuring user access by account group.

Note: The restrictions configured for project account groups do not affect the visibility of account groups on the Balances tab of the Projects (PM301000) form. That is, the system still show the total balances by each account group regardless of the access rights of a user. The user with insufficient access rights for a particular account group will not able to review the detail information for the project transactions that include this account group.

If you configure a user to have no access to a particular account group, this user cannot enter and release project transactions that include lines with this account group on the Project Transactions (PM304000) form. Also, on the following forms, the user is not able to view transactions that include the restricted account group in the Debit Account Group or Credit Account Group box:

Important: On any of these forms, if any transaction lines are hidden because a user is denied access to the account group, the system displays a warning and calculates the totals shown on the forms based on the visible transaction lines.

For example, suppose that you are a system administrator, and you have to configure the visibility of project transactions to the appropriate users considering the following:

There are two users for which you need to configure the visibility of project transactions in your organization: User A and User P.
User A, the accounting manager who controls work of the accounting department, is allowed to see all financial information. This user enters project expenses related to employee labor.
User P, the project manager who manages the project. is allowed to enter and view project transactions for project expenses related to cost of materials and subcontract work. The user must not be able to see sensitive information related to employee labor for the project

To configure the described security scenario, the system administrator does the following in the system:

On the Account Groups (PM201000) form, configures the MATERIAL (for material expenses), SUBCON (for subcontract expenses), and LABOR (for employee labor expenses) account groups, and maps the appropriate general ledger accounts to these groups.
On the Project Transaction Visibility by Account Group (PM103000) form, creates a new restriction group with the B Inverse type and adds User P and the LABOR account group to this restriction group.

With this configuration, User A enters project transactions with employee labor related to project and selects the LABOR account group. Access to this account group is restricted for User P, who is able to review the project transaction lines with the MATERIAL and SUBCON account groups but cannot view the lines with LABOR account group on data entry forms and in reports.

Forms for Project Security

In the following table, you can find the list of the forms that you can use to manage restriction groups with projects. The table also includes the task that you can perform by using each form.

For information about how to add or remove objects from a restriction group, see Operations with Restriction Groups.

Table 1. Forms for Project Security
Task	Form
To initially configure the visibility of a project to users	Project Access (PM102000)
To change the visibility of a project in multiple restriction groups	Restriction Groups by Project (PM102010)
To change the visibility of projects to a user in multiple restriction groups	Restriction Groups by User (SM201035)
To change the visibility of project transactions with particular account groups to a user in multiple restriction groups	Restriction Groups by Account Group (PM103000)