This feature fully automates how address updates are handled for orders that are already planned on routes.
When an address is modified, the system automatically evaluates whether the change can be applied directly to the existing route, or whether it would introduce too much disruption, and takes the best decision to ensure the route stays efficient.
Configuration
The feature is controlled through a single configuration parameter:
Address Change Tolerance, defined in minutes
Configured at organization level (managed by Mover Support)
What it means
The Address Change Tolerance defines how much the route is allowed to change when an order’s address is updated.
When an address is modified, the system evaluates the impact by comparing:
the new driving time, calculated as the route segment previous stop → new address → next stop,
against the original planned driving time for the same segment.
The difference between these two values represents the impact of the address change.
Once the impact is calculated, the system uses the configured tolerance to decide how to handle the update:
If the impact is smaller than the configured tolerance, the change is considered acceptable and the stop address is updated directly on the route.
If the impact is greater than or equal to the tolerance, the change is considered too disruptive and the order is removed from the route, triggering the standard removal flow.
This ensures that only changes with a limited operational impact are applied automatically, while larger disruptions are handled explicitly.
Special values
If the tolerance is set to 0, any address change will be considered too large, and the order will always be removed from the route.
If the tolerance is left empty (null), the feature is effectively inactive. In this case, address updates do not attempt to preserve the route, and all changes result in the order being removed.
Execution
How it works
When an order’s address is updated, the system evaluates whether the change can be applied without disrupting the route.
The process follows these steps:
Check if the order is planned on a route: If the order is not part of any route, the system simply updates the address and no further action is taken.
Validate whether the stop is eligible for update. If the order is on one or more routes, the system verifies a set of preconditions. If these conditions are not met, the system will not attempt to update the stop address and will instead follow the removal logic where applicable:
the stop must be in status “not visited”
the stop must not be a distribution center
the stop must be eligible for update based on structural constraints (e.g. multi-order rules described in the Special Cases section)
Calculate the driving-time impact. The system computes the impact of the new address by comparing the simulated updated route segment with the originally planned one. This results in a time difference expressed in minutes.
Apply the tolerance rule. The calculated impact is then compared to the configured Address Change Tolerance:
if the impact is within tolerance, the stop address is updated directly on the route
if the impact is greater than or equal to the tolerance, the order is removed from the route
This ensures that only manageable changes are applied automatically, while larger disruptions are handled explicitly.
What happens when an order is removed
If the system determines that the order must be removed from the route, it executes a series of actions to keep operations consistent:
The associated colli are marked as cancelled. If no active colli remain on the stop, the stop itself is automatically cancelled.
If any colli have already been picked up, the system creates a return stop and assigns those items to it, ensuring they are routed back to the pickup location.
An event is recorded in the order history: “Order removed from route – Reason: Address changed”
This provides traceability and allows support and operations teams to understand why the order needs to be re-planned.'
Special Cases
1. Driver already arrived at the stop
If the driver has already arrived at a stop, the system considers it too late to safely apply address changes.
For delivery stops, no change is applied. The order remains as planned to avoid disrupting execution.
For pickup stops, the order is removed from the route. The associated colli are cancelled, and the Driver App is refreshed to ensure the driver does not proceed with the pickup.
2. Stop has multiple orders
When a stop contains more than one order, the system evaluates whether it is allowed to update the address at stop level.
If the stop does not have the “all-or-nothing” setting enabled, the system cannot safely update only one order. In this case, the order is always removed from the route, regardless of the size of the address change.
If the stop does have the “all-or-nothing” setting enabled (e.g. multi-pickup / EMPU scenarios), the system treats all orders as a single unit. The address can be updated only if:
all orders belong together (same sales order), and
the address change is within the configured tolerance.
If these conditions are not met, the order is removed from the route.
3. Stop is a Depot (Distribution Center)
Address updates are not supported for depot stops.
If an address change is received for an order planned on a depot stop, the system will always remove the order from the route, regardless of the size of the change or configuration.
4. Order already picked up
If the order has already been picked up when the address is changed, the system cannot simply remove it without handling the physical goods.
In this case:
the order is removed from the delivery stop
a return stop is automatically created
all picked-up colli are assigned to this return stop
This ensures that the goods are routed back to the original pickup location.
5. Driver arrived at pickup and delivery address changes
If the driver has already arrived at the pickup location and the system determines that the order must be removed from the route (e.g. due to a large address change), special care is taken to avoid incorrect execution.
the order is removed from the route
the colli are cancelled
the Driver App is force refreshed
This prevents the driver from picking up items that are no longer part of the plan.
6. Address change improves the route (negative impact)
In some cases, the updated address results in a shorter or more efficient route, meaning the calculated impact on driving time is negative.
This happens when the new address reduces the total travel time compared to the original plan (e.g. the new location is closer to neighboring stops).
In these situations:
the change is always considered acceptable from a routing perspective, since it improves efficiency
the stop address will be updated, provided all other conditions are satisfied (e.g. stop not visited, not a depot, and eligible under multi-order rules)
A negative impact will never cause the order to be removed from the route, even if a tolerance is configured, because it represents an improvement rather than a disruption, and the alternative (removing the order from the route) would still leave a hole in the route.
Linked Features
Notifications: “Order removed from route”
You can configure notifications when an order is removed due to address change.
Where: Communication settings → Event templates
Event: Order removed from route, Reason: Address changed
Who can be notified
Customer Support (via email)
Delivery customer (email/SMS)
Pickup customer (email/SMS)
Purpose:
Trigger rebooking process
Inform customer proactively
Reduce WISMO (“Where is my order”) calls
Key Takeaways
Small address changes are handled automatically by updating the stop directly on the route, allowing operations to continue without unnecessary disruption.
Larger changes, which would significantly impact the route, result in the order being removed and made available for rebooking, ensuring that planners can reassess the situation properly.
The system is designed to balance route stability with operational control, avoiding unnecessary re-planning while still protecting execution quality.
Full visibility is maintained through order events and configurable notifications, enabling support and operations teams to quickly understand what happened and take appropriate action.