Staff

Configuration > Staff and resources > Staff

List

Staff can be listed in three ways:

• “is designated staff at” is a default option (previsously staff search worked by this criteria)

• has employee number for company lists persons with an employee set for a specific company

  • Uses the new functionality that allows that employee number is set on company level and not on system level.

  • Automatically selects first company from company dropdown as default

  • Disables facility dropdown

• “has access to”

  • The search result always includes persons with accesstoallcompaniesandunits set to true

  • If you select only facility - then search result includes persons with access to this facility

  • If you select only company - then search result includes persons with access to selected company + person with access to any facility within this company *

  • If you select company and facility - then search result contain persons with access to company and person with access to selected unit

  • If you unselecet both company and facility - then search result includes persons with access to any company or facility

Open

Click to expand image

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):

   • Make changes at the central level (affecting all facilities), or

   • Make changes at the local level (affecting only the companies and facilities the user has access to).

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"

   • The staff member can access all companies and facilities.

   • It’s not necessary to select individual companies or facilities in the other two fields.

   • Can only be set by a user who has the right “Staff” and who themselves has “Access to all companies and facilities.”

   • Recommendation: Only enable this for central staff who need to log in and manage all companies and facilities in the installation. You don’t need to add access to specific companies or facilities if this is active.

2. "Company"

   • The staff member can access these companies and all the facilities belonging to them.

   • A user with the right “Staff - Change Company” (language string) can add or remove access to companies for a person (staff), but only for companies the user themselves can access.

   • Recommendation: Enable this for staff who need access to all facilities in that company, including future new facilities. You don’t need to add these facilities in the next step; having the company is enough.

3. "Facilities"

   • The staff member can access these specific facilities.

   • They cannot access the company settings for the facilities, unless direct access to the company is granted.

   • A user with the right “Staff - Change Facility” can add or remove facility access for a person (staff), but only for facilities the user themselves can access.

Open

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"

   • Allows making changes to objects in Configuration that affect the entire installation.

   • Recommendation: Only enable for a small number of people who, at a central level, need to modify products and other objects shared by all facilities.

2. "Access to other facilities’ customers"

   • If the role has this right, the functionality remains as before (pre-2021 changes). The user can see customers linked to facilities the user does not have direct access to.

   • Recommendation: In a chain of facilities, you typically want to enable this so staff can manage customers moving between facilities. It’s often correct to grant staff this right.

3. "Access to other facilities’ objects"

   • If the role has this right, the functionality remains as before, and the user can access other objects (resources, products, etc.) not connected to a facility they have direct access to.

   • Recommendation: Usually do not enable this.

4. "Central user"

   • Legacy. Should NOT be enabled for any role.

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

• Users can see objects that affect them:

  • System-level objects

  • Objects tied to companies they have full access to

  • Objects tied to companies that have one or more facilities the user can access

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

• The right "Access to objects at system level" is required for system-level objects.

• Full access to a company is required for company-level objects.

• Access to all facilities, or full access to the company/companies those facilities belong to, is required for facility-level objects.

• In all cases, other rights may also be required depending on object type (e.g., "Cashier Pages - Edit" for creating, editing, or deleting cashier pages).

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:

• Belonging to a facility they have access to,

• Belonging to a company whose facility they have access to, or

• System-level objects.

Special case: Person list

• If the user’s role has “Access to other facilities’ customers,” they can see all persons in the installation.

• If not, they only see persons:

  • Linked to the facilities they have access to, or

  • Who have subscriptions linked to those facilities.

Exceptions:

• When searching for a person by full personal identity number, the system can find persons at other facilities (to avoid duplicates).

• When searching for card/wristband with Ctrl+F3 or via “Card information” in the top bar, the system can find all persons scanned/entered by card number. They are physically present at the user’s facility.

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:

   • Product:

     • Local price

     • Warehouse location (stock item)

     • Add/remove own facilities

   • Resource:

     • Add/remove own facilities (not changing links to other facilities, nor removing a resource if it’s linked to one or more facilities the user doesn’t have access to)

   • Follow-Up Points:

     • Activate/deactivate for own facilities

   • Invoices:

     • Full access

   • Autogiro/Avtalegiro Authorization:

     • Full access

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.

   • Everyone can see system-level objects.

   • To edit these objects, the user needs “Access to objects at system level.”

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).