1. Home
  2. Docs
  3. Employee Sync
  4. Mapping
  5. Department, Role & User Mapping

Department, Role & User Mapping

Once the location mapping UI and backend has been implemented, you can reuse those components for department, role & user mapping as well. You will then need to store the corresponding 7shifts ID for each entity in your system.

There are certain ways in which department, role & user mapping would differ from location mapping. The differences are listed below:

Departments

  • You will need to store the ID of the department as well as the ID of the location that the department belongs to
  • When presenting the UI for department mapping, please ensure that it is made explicit what location the departments are going to be mapped for
  • You can get a list of all departments within a specific location to populate the 7shifts departments dropdown as follows:
GET https://api.7shifts.com/v1/departments?location_id=12345
  • Note: If your system doesn’t support the concept of departments, you do not need to show a department mapping UI. Instead, in the role mapping process (as outlined in the next part), ensure that the department_id returned for each role is stored in association to the role_id for each role in your system

Roles

  • You will need to store the ID of the role as well as the IDs of the location & the department that the role belongs to
  • When presenting the UI for role mapping, please ensure that it is made explicit what location & department (if applicable) the roles are going to be mapped for
  • You can get a list of all roles within a specific department to populate the 7shifts roles dropdown as follows:
GET https://api.7shifts.com/v1/roles?department_id=98765
  • In case you don’t support the concept of departments or if a 7shifts account doesn’t have departments (roles associated directly to locations), you can get a list of all roles within a specific location as follows:
GET https://api.7shifts.com/v1/roles?location_id=12345
  • Note: If the roles returned in the second request response have a department_id set to 0, that means the role is not assigned to a department but is directly assigned to the location. When creating time punch data for such roles, the department_id will need to be set to 0 as well

Users

  • You will need to store the ID of the user as well as the IDs of the locations, departments and roles that the user belongs to
  • Since users can be assigned to multiple locations, multiple departments and multiple roles, their mapping is agnostic of locations, departments or roles
  • You can get a list of all active users as follows for the mapping UI:
GET https://api.7shifts.com/v1/users
  • If you need to get a list of all active & inactive employees from 7shifts, you can use the active URL query parameter as follows:
GET https://api.7shifts.com/v1/users?active=0,1
  • You must only use the results where the user_type_id field is equal to 1. This denotes that the user profile in question is an employee profile. Anything else should be ignored as this integration isn’t meant to support Admin, Manager & Assistant Manager profiles.
  • The ID that you must store in relation to a user is the id field in each user object in the response. There are other fields named employee_id and payroll_id — please ignore those for the purpose of this integration
  • Since you also need to know which roles a user is assigned to and the IDs for those roles, you will need to make the following request to get a user’s assigned roles:
GET https://api.7shifts.com/v1/roles?user_id=246800 
  • Note: Users can either be in an active or inactive state in 7shifts. The above request will only return active employees. If inactive employees need to be mapped, the admin/manager must activate the employee in 7shifts before completing the mapping