Permissions or Role-Based Access Control (RBAC) is a tool that makes it easy to manage who does what in our system. We group users into roles based on their jobs, and each role comes with rules about what they can and can't do. This makes sure everyone only gets access to what they really need, making things organized and safe.

Predefined user roles and permissions:

In the RBAC functionality, there will be some default roles with pre-defined permissions.

1. Onboarding Admin: Users who are added as Admin on the onboarding and offboarding dashboard can take all the actions that are currently live on the dashboard. There will be no restrictions for Admins. Onboarding Admins permission cannot be changed from the permission tab.

2. Onboarding agent: Onboarding agents can take all the actions that are live on the dashboard but only against those candidates that were added by the user himself. They can also add candidates to the dashboard. For example: Two employees A & B have added two candidates Y & Z respectively. In this case, Employee A can perform all the actions against user Z but cannot see Candidate Z in the candidate list on the dashboard because that was added by Employee B.

3. Onboarding Viewer Role: Users who are added as a viewer on the dashboard can only view the onboarding module from the left panel but when they open the module, they will not see any user and will get a message to contact Admin for more permission, as shown in the image below.

How Onboarding users will be added to the dashboard:

All the Onboarding users will be added to the dashboard through the settings page of the unified dashboard. While adding the users, the admin will have to define whether the added member will act as an onboarding Admin/Agent/Viewer, as shown in the image below.

Adding a user to the dashboard will be done through the unified dashboard settings tab and all the roles-based access will be done from the onboarding and offboarding permission tab.

In the unified dashboard we can add users in 2 different ways:

• As a group: In the global setting page we have the option to add multiple people as a group. Ex: If HR admin wants to add 5 users and all 5 users' role is of clearance owner, then, in that case, Admin can create a group on the unified dashboard named clearance owner, add all the 5 users' details in that group, define their role (admin/default access) and add them to the dashboard.
• As an individual: Admin instead of creating a group and adding users under them they can individually also add the candidate to the dashboard through the global settings page. Journey: Add user >> Add user details>> Define the role (admin/default access) and add the candidate to the dashboard.

Different permissions that the Admin can define via the dashboard are listed below:

How Admin will define the permissions against each user:

• Admin can define user's and group permissions through the permission tab which is available under the Onboarding & Offboarding module.
• When the admin opens the permission tab, they will see the list of all the users that are added under that module. In the list view, we will show the user's details like name, email, and what role they have been granted or the group they are part of. Along with the user list admin will also see a list of all the groups that are created for that module.
• Admin can give permissions at the user level or at the group level. The group is the same which admin has defined while adding the user through the global settings page. Permissions defined for a group will be applicable to all the members who are part of that group.
• Admin permissions cannot be updated from the permission tab. Only Agent and Viewer user and group permission can be updated.

Listing down different ways through which a user can be added to the dashboard and permissions granted to them along with examples:

Individual Level:

• The user is added as an individual user and only a predefined role is assigned to him:
  • If a user is added to the dashboard with a predefined role(Agent or viewer) and Admin does not update any permissions against that user. In this case, whatever permissions were defined against that role will be applicable to the user and they can take only that action on the dashboard. Ex: If a user is added as an onboarding agent on a new bot then he can take all actions against those candidates that were added by the user themselves.
• The user is added as an individual user with an Onboarding viewer/Onboarding Agent role and the Admin went ahead and defined custom permissions for them.
  • User added as an Onboarding Viewer: If user A is added to the dashboard as an onboarding viewer then as per the new bot he will not have any access. Now let's say Admin opened the user permission tab and defined certain permissions like Add candidate, Edit Section, View all candidates added by the user, and can Change only their onboarding status. Once this permission is saved we will replace the older permission with the new one and when user A logs in to the dashboard he can see the Add Candidate option, he can see all the candidates that were added by user A, and for those users, they can change their onboarding status and edit their section fields.
  • User added as an Onboarding Agent: If user B is added to the dashboard as an onboarding Agent then as per the new bot he can take all the actions against those users that were added by user B. Now let's say the Admin opened the user permission tab and from there he gave the following permissions to the user where he cannot add candidates, he can view all the candidates and can change the onboarding status. Once the permission is saved the originally applied permission will be replaced with the new one and when user B logs into the dashboard he can view all the candidates and can only change their onboarding status.

Group Level:

If the user is added to multiple groups or if the user gets permission from the group as well as Admin gave additional permission at the user level then in that case we take the union of all the permissions that the user is getting from multiple sources and allot the permissions accordingly. If there is a conflict between permission in that case we take the one that has got higher priority. Ex: If the user has edit access through a group and view access through another group then in that case we will allot edit access to the user. Similar way if a user has got add candidate permission from one group and from another it has not got add candidate permission then in that case user can still Add the candidate. Listing down all the cases below with examples for better understanding.

• The user is added to one group and that group permission is updated by the Admin:
  • User and Group are given Onboarding viewer roles: Let's say Admin has created group A and added employee 1 to that group. Both groups and users are added as an onboarding viewers. In this case, employee 1 will have no access for now. Now let's say the Admin gave the following permissions to the group: They can add candidates, Edit the section, update the candidate details, View all the candidates, and change their onboarding status. Once this permission is saved Employee 1 when logging in to the dashboard will be able to perform all the above-mentioned actions.
  • User and Group are given Onboarding agent roles: Let's say Admin has created group B and added employee 2 to that group. Both groups and users are added as an onboarding Agent. In this case, Employee 2 will have only the default agent permissions(new bot) right now. Now let's say the Admin gave the following permissions to group B: They cannot add candidates, View all candidates, Download the report, and change their onboarding status.
    • After saving these permissions at the group level our system will do the union between Employee 2 default role(OB agent in this case) and the group-level permission and allot the permissions accordingly.
    • If there is a conflict between permission in that case we take the one that has got higher priority. Ex: If one user has edit access through a group and view access through another group then in that case we will allot edit access to the user.
    • So for the following permission that is mentioned above when employee 2 logs in to the dashboard, they can do the following things: They can add a candidate, View all candidates, download the report, and change all users onboarding status.
• The user is added to multiple groups:
  • This will also work in a similar way we have explained above. Giving an example for reference.
  • Let's say employee 1 is added as an onboarding viewer and he is part of multiple groups A and B. From Group A he got the following permissions he can only view those candidates where the manager email ID of a candidate is matching with that of employee 1 email ID and they can only change the onboarding status of those candidates. From Group B he got the following permissions: Add candidate, Edit sections field, Update candidate details, he can only view those candidates where the HR email ID of a candidate is the same as ‘[email protected]’ and they can also push data to SF.
  • We will do the union of group A, group b, and individual user permission and allot the permission accordingly.
  • When Employee 1 accesses the dashboard he can now Add a candidate and view all the candidates where the manager's email ID matches with Employee 1 email ID and the HR email ID is ‘[email protected]’ and can update their onboarding status, edit the section fields and push their data to SF.
• The user is added to a group and Admin gives additional permissions to the user from his detail page:
  • Let's say employee 1 is added as an onboarding viewer and he is part of group A which is also allotted Onboarding viewer. Now let's say for group A we have defined the following permissions: Add candidate, Edit section field, View only candidate added by the user, Change their status, View all the forms.
  • Now Admin went to the Employee 1 permission tab and gave the following additional permission: They cannot add candidates, View all candidates, and edit only personal information forms.
  • We will do the union of Group A and Employee 1 individual permission and allot the permission accordingly.
  • When employee 1 accesses the dashboard he will be able to add candidates, Edit the section field, View all candidates, Change their status, and they can view all the forms but can edit only the personal information form.