1. Home
  2. Docs
  3. Labor Integration
  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
  • 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