Configuration > Staff and resources > Staff

Staff Access to Companies and Facilities

Talk to your BRP contact before making any adjustments. The right “Access to other facilities’ objects” on roles provides the older behavior. The stricter access control described below takes effect for a role once that right is removed.

Purpose

  1. Allow system administrators for a company or a facility to manage resources, prices, and other objects in BRP Configuration without affecting other facilities.

  2. Allow other users to access what they need in BRP Back Office, BRP Resource Planner, BRP Point of Sale, BRP Entrance View, and BRP Sales Management without unnecessarily granting access to other facilities’/companies’ customers or objects.

  3. Make it safer for many companies and facilities to coexist in a single installation by specifying, for each role, how users deal with shared objects (e.g., products):

Configure Users’ Access to Companies and Facilities

On the “Facilities” tab in each staff member’s card, set the following:

  1. "Access to all companies and facilities"

  2. "Company"

  3. "Facilities"

Role Rights That Affect Functionality

Changing these rights greatly impacts users’ access to other facilities. Make changes one role at a time and in a controlled manner!

  1. "Access to objects at system level"

  2. "Access to other facilities’ customers"

  3. "Access to other facilities’ objects"

  4. "Central user"

New Behavior in Lists of Objects That Only Belong to a Single Company or Facility

Most objects are tied to only one company or facility.

In BRP Configuration

Users should see all objects that affect them but can only modify or remove objects that exclusively affect companies or facilities they have full access to. For example, if a user only has access to Facility X belonging to Company A, they can’t delete a schedule at the company level (A) because it would affect other facilities in Company A.

Filter

Lists in Configuration that mix objects at the system level, company level, or facility level (e.g., schedules) let the user filter by either a single company or a single facility (not both).

Example:
If the user selects Facility X, the system shows objects linked to that facility, the facility’s company, and system-level objects. All these affect users logged in at Facility X.

Viewing

Special case: Product list
When filtering “Not in use,” the user can see other facilities’ products and link them to their own facility. This avoids creating duplicates if it can be prevented and still allows meaningful sales statistics for the whole installation even when sales occur in different companies.

Create / Change / Delete

In BRP Back Office

Users generally only see objects linked to the facilities they can access (there are a few practical exceptions).

Filter in Object Lists

Users can see objects:

Special case: Person list

Exceptions:

Lists of Objects Shown on Other Object Views (MOV in SOV)

Example: Subscription List on a Person Card

When a user has access to an object (the person card), that user can see all objects in the lists on that view (e.g., subscriptions, value cards, etc.) even if the user does not have facility access to the objects in question. This is to allow good customer service. However, the same objects are not accessible in, for example, the main subscription list, so the user cannot easily compile a list of all subscriptions in a company they do not have access to.

Levels of Access to Shared Objects

Some objects belong to multiple companies or facilities. When an object is opened or manipulated via a button (action) in an object list, the system allows modifications based on one of three levels of access. This level is determined by the user’s rights and access to facilities, companies, or system level.

If an object (e.g., a product) is used by several companies or facilities, a user can’t remove the link to companies/facilities they lack access to.

Some special rules apply to objects such as products and resources shared by multiple companies/facilities. In those cases, some users may change only properties for their own companies/facilities (e.g., a local price).

  1. Read-Only Access
    Used when, based on rights and facility access, the user cannot alter an object.

  2. Local Level
    Used when the user doesn’t have access to all facilities an object belongs to. The user can make limited changes (according to the role’s rights) that only affect their own facilities—e.g., local pricing on a product.

    Objects that support local-level access include:

  3. Standard
    Used when the user has full access to all facilities the object belongs to. Grants full access to the object (within the role’s rights).

  4. System Level
    Objects lacking any company/facility link affect the entire system.

Limitations

Certain system areas where a button in an object list performs actions on all selected objects do not yet have facility-access checks in place—for example, mass edits of subscriptions (although that is limited by a separate right).