OneBoxBM uses a tiered/layered permissions system that allows you to set permissions for all system users, groups of users and individual users.
When setting up permissions in OneBoxBM the main points to be aware of are.
The primary user account is created as part of the registration process. As the account holder, the primary user has full access to all of the systems features and all data stored within the system.
This means that they can see the full details of every record regardless of who created it.
The primary account holder is also responsible for managing everything relating to the management of the My Business subscription.Therefore, they are the only ones who can access the Account Management area.
Super users are the next step down from the Primary User. Like the Primary User, they have full access to all records in the system regardless of who created them.
Due to the lack of access restrictions in place, we recommend only using super users when:
Standard user accounts are where the permissions actually come into play, as access to the systems features is limited by the assigned permissions.
Permissions in OneBoxBM can be assigned to:
When determining whether or not a user can perform certain actions or access specific records, the system will check if the user has been granted access at any level.
This means that if you grant access to something at the all-users level, every user can perform that action.
The same applies if you grant access to a specific user group, all users of that group will be able to perform that action.
It is possible to grant access to perform certain actions against employment records only if the employee is part of a certain group.
This means that you can have users that can approve holiday requests for employees in their department and not departments managed by other users.
When managing permissions, you may notice that some of them are flagged as being inferred.
This means that the relevant users will be able to perform the action, but they have not been granted explicit access to take that action.
For example, a user with the ability to manage holiday requests for other employees will automatically have access to both view and manage requests for those employees as well.
Should their access to manage the requests be revoked then they will no longer have access to view or manage the holiday requests for other employees.
In addition to this, permissions will also be displayed as inferred if access was granted at a lower level.
So if you grant access to view the holiday requests for other employees at the all users level, the access will be classed as inferred when viewing it from the perspective of a user group or individual user.
See below for what we feel is the best way to manage your users access.
Using groups allows you to grant access to certain features to a number of users, but it also allows you to restrict access by omission (users have to be added to groups).
Even if you only want to assign permissions to a certain user, we would still recommend creating a user group as the user might leave the business, take extended leave or move to another area of the business/company.
While your first instinct might be to simply create groups based upon department or area of the business, like so:
Doing so will limit your ability to effectively make use of employee groups as you would typically want things like holiday requests to be approved by a more senior member of staff. Instead, we recommend.
The above not only allows you to assign different permissions to each group, it also allows you to assign different levels of access depending on which employment records they are trying to access.