This is a new feature. We plan to expand the feature in the future with new permissions. Follow the page for updates!
In this article, we explain the taking into use and utilization of permission sets within an organization. Permission sets offer a precise method for managing access rights in Nepton. Within a permission set, administrators can define which data users have viewing rights to and which data they have editing rights to. Permission sets are used in conjunction with a new concept, person group access. This enables users to be granted different rights to various person groups. The user does not have to be a member of the person group, but they are given access to the selected person group.
Permission sets are particularly suitable for the needs of large enterprises, enabling precise access control based on organizational structure and roles. When creating permission sets, administrators can take data privacy into account by granting users access only to the data and groups they need for their roles.
Taking permission sets into use
Here is a brief guide to taking permission sets into us:
- Creating Person Groups: If person groups have not yet been created within the organization, create suitable person groups representing the organizational structure, teams, or roles. This is done in the section Worktime > Administration > Person Groups.
- Creating Permission Sets: Create a permission set and define the desired rights, such as viewing rights to certain data and editing rights to certain data. This is done in the section Employees > Permissions > Permission Sets.
- Assigning Rights in Person's Information: Select the person to whom you want to grant rights. In the person's information, under Access to Person Groups, select the permission set that defines the person's rights. Additionally, select the person group that defines which group the person has these rights in.
If a person has been assigned multiple rights in different person groups in such a way that they overlap (the person has more than one relationship to a person group, directly or through inheritance), the permissions are combined.
Examples of Use Cases
Receptionist
- Create a permission set named "Receptionist" with permissions to view people's names and phone numbers, as well as to edit RFID tags.
- A person acting as a receptionist is given the "Receptionist" rights in relation to a person group representing a physical location, such as the Espoo branch. The Espoo branch person group may have multiple subgroups.
- The receptionist now has access to search and view all people working in Espoo, see their names and phone numbers, and edit/add RFID tags at the reception desk, which are required for building access.
Country Reporter
- Create a permission set named "Reporter" with rights only to view and report on non-sensitive worktime data, such as event hours, projects, and basic absence information.
- The person responsible for reporting in a country is given the "Reporter" rights combined with a country-level person group, allowing reporting on all worktime data in that country.
Worktime permission
The currently supported worktime permissions that can be granted with a permission set (marked with x).
View | Edit | Approve | |
Worktime events | x | x | x |
Sick leave medical certificate | - | x | - |
Sick leave compensation | x | x | - |
Sick leave reason code | - | x | - |
Worktime event attachments | x | x | - |
Persons' settings and projects in worktime | - | x | - |
Person field permissions
Permissions can be granted to all person fields with a permission set.