Is it possible to assign a user to the master bureau account (granting the login access to all company and employee information within the tenant), but at the same time (at creation) select from a list of companies that the user shouldn't see? The goal: 1. by default let the login have access to all companies and information, including new ones that get uploaded at later dates 2. limit their access and ability to see certain existing companies as necessary while keeping them a part of the master bureau
Hello Micah,
the solution that fits your goal best is to utilize 'User Roles', more information can be found on page 287 of our official documentaion, Rollbase in Action. More specifically, a 'Role' defines the Permissions that a user may have in viewing, creating, editing, and deleting objects and applications.
To create a 'Role':
- Navigate to SETUP > ADMINISTRATION SETUP > ROLES. You will be brought to the 'Roles' page which displays all available 'Roles'.
- Click on 'New Role', you will then be brought to a page which asks you to give this new 'Role' a name, 'Integration Code', and 'Description'. Most importantly, you will be able to select the 'Applications' that you'd like this particular 'Role' to have access to. By default, the 'Selected Applications' that are chosen for the 'Role' grant:
-------- Access to the Application
-------- View, Create, Edit, and Delete permissions of the Objects/Records involved
--------
The solution offered would work in the case that there was only one user or group of users that needed to share the same permissions. However, in this case, there will be multiple users all with their own set of permissions needing to be set. It is possible for every user to need their own set of unique permissions. To add to that, the permissions will need to allow for user editing by roles not at administrator level.
The solution I developed:
Make the user pick the companies they wish the user not to see at user creation. The company object (that is connected to the user object) can then filter its views to only let the user see companies not specified as hidden by the user at creation or after updating.
A trigger in the user object also runs to attach the user to all employees and their data that the user creator doesn't wish the new login to see. the views for the employee object can then be filtered not to sure employees attached to the login.
The end result allows the user to create and/or edit