Transport Boundary feature

This document outlines how to manage employee transport boundaries and how the system enforces these boundaries during employee profile creation and updates.

Problem statement:

Many organizations offer employee transportation only within a specific radius or distance from each office. Since these distance limits can vary from office to office, it's essential to manage employee addresses in relation to these transport boundaries.

This ensures compliance with company transport policies and proper allocation of transport resources. 

Solution:

• Our system supports the definition of custom transport boundaries for each office.  
• Employees residing outside these boundaries are ineligible for company-provided transport.
• The system enforces this by preventing address updates or new employee creations with addresses outside the defined transport boundary.
  
  

Defining Transport Boundaries:

1. Office-Specific Boundaries: Transport boundaries are defined on an office-by-office basis.  Each office can have one or more defined boundaries.
2. KML File Format: Boundaries are created using a mapping tool (e.g., Google My Maps) and exported as a KML (Keyhole Markup Language) file.  You can create custom boundaries at https://www.google.com/maps/about/mymaps/.
3. Separate KML Files: Each office requires its own separate KML file(s) to define its specific transport boundary/boundaries.
   
   

E.g. Sample KML file of a transport boundary

Use case-1:

Employee Profile Creation/Update:

Employee profile creation and updates are handled via data sync or front-end. The information must include geocodes for address validation. The system performs the following checks:

• Editing Existing Addresses: Editing an existing employee address to a location outside the defined transport boundary is not permitted.  The update will fail with an error message.
• Creating New Employees: Creating a new employee profile with an address outside the defined transport boundary is not permitted. The creation will fail with an error message.
  
  

P.S. By default, it will not block the existing profiles but it will come into effect only when any changes are made to the profiles.

Use case-2:

MAKE_NON_TRANSPORT_USER_WHEN_OUTSIDE_TRANSPORT_BOUNDARY 

For any user, if the address is outside of the defined boundary region, the user will be marked as a non-transport user.

P.S. It will not block the creation or editing of the address beyond the defined region.

usersBy default, it will not make the existing profiles as non transport user but it will come into effect only when any changes are made to the profiles.

Special use-cases

Case-1

Allow Profile Creation and Control Cab Scheduling.

Problem

The current transport boundary feature blocks profile creation for users outside the boundary. This creates an issue for employees using both bus and cab services, as buses operate beyond the boundary, but profiles cannot be created for bus riders living outside it.

Solution

Profile Creation: Employees can now create or update profiles, regardless of the transport boundary, via both UI and data sync.

Scheduling:

• Employees within the boundary can book cabs as usual.

• Bus booking is allowed for all, even outside the boundary.

• Cab bookings from outside the boundary will fail during submission.

Case-2

Allow an Employee to Schedule Cab Outside Transport Boundary as an Exception

Problem :

When an admin flags an employee as a transport user who is outside the boundary, the system allows the change but then disables the flag upon saving the profile.

Solution :

• ALLOW_TRANSPORT_BOUNDARY_EXCEPTION" will introduce an additional flag in the employee profile- "Transport Boundary Exception".

• This flag will enable the "Transport User" flag to override scheduling privileges, regardless of the employee's transport boundary status.

• Once the exception is marked the status set by the admin will be permanent until the address is changed.

THANK YOU