External release notes – Grasshopper – Version 3.24.19
New Features
- New Feature: Pending Pickup Age Column in Orders Grid
- We’ve added a new “Pending Pickup Age” column to the Orders grid to help pickup teams make more informed and timely decisions regarding outstanding orders.
- This enhancement provides visibility into how long each order has been pending pickup or pending return, enabling operational teams to prioritize actions based on order aging.
- Key Enhancements
- New Column: “Pending Pickup Age”
- Displays the number of days since the order was created, as long as the order is in a relevant status.
- Status-Based Logic:
- Pending Pickup: Days since order creation
- Pending Return: Same logic applied for return orders
- Hold Status: Days in hold are included if the hold occurred before the order was picked
- New Column: “Pending Pickup Age”
- New Feature: Robocall Scheduling Logic & Retry Control
- To improve the reliability and user experience of customer robocalls, we’ve enhanced the system’s logic to avoid unnecessary retry loops and better respect business hour constraints.
- This update addresses issues reported by clients where robocalls were repeatedly failing due to being scheduled outside of business hours and retried every 24 hours without success.
- Key Enhancements
- Improved Retry Behavior: Robocalls that fall outside of configured business hours will now be rescheduled to the next available valid time, mirroring the behavior of text messages. Prevents infinite retry loops for calls made during closed hours.
- Updated Tracking Message: The robocall tracking entry now displays a clear and informative message: “Request to schedule Robocall to customer sent (to phone number: xxx-xxx-xxxx at: 11-20-2024 09:30 AM EST).”
- Improvements
- Support for running up to 3 robocalls in parallel for increased throughput.
- The robocall plugin now intelligently avoids executing outside business hours.
- Robocall success/failure metrics are logged to track how many were attempted vs. successfully completed.
- Display Last-Mile Delivery Date on Shipping Labels
- A new label enhancement has been introduced to provide warehouse teams with clear visibility of the expected last-mile delivery date directly on item shipping labels.
- Key Enhancements
- Label Content Update: The Scheduled Last-Mile Delivery Date is now included on the label for eligible orders. This helps warehouse staff better understand delivery priorities and timelines.
- Feature Flag Control
- This request requires a feature flag enabled
- The feature is disabled by default
- Advanced Settings
- Advanced Settings → Orders Tab → Documents Section → Shipping Label
- User Interface Enhancements
- Toggle Control: Enable/disable the feature per account from the Advanced Settings.
- Preview Button: A new “Preview” option opens a pop-up showing an example label.
- Preview asset reflects the new scheduled date layout.
- Conditional Display Logic
- The scheduled delivery date will only appear on labels if:
- The feature flag is enabled
- The order has a Scheduled Date
- I f either condition is unmet, the label will not show the scheduled date section.
- The scheduled delivery date will only appear on labels if:
- Unified Arrival Tracking in Driver App
- A new enhancement has been introduced to standardize the “Arrived On Site” button across all order types in the Driver Mobile App.
- This update ensures consistent workflows for drivers at every stop and improves tracking of arrival times for reporting purposes.
- Previously, the “Arrived On Site” button was not available for certain order types, including:
- Pickup Orders (from vendors, customers)
- Service Tickets
- Return Orders
- This inconsistency led to workflow variations and gaps in tracking driver arrivals.
- Key Enhancements
- Unified “Arrived On Site” Button Across All Stops
- Improved Customer Interaction Flow
- Simplified UI – Removal of “Take Action” Button & Popup
- How it works
- Navigate to Advanced Settings > Orders.
- In the Documents section, open the Shipping Label settings.
- Toggle on “Enable last mile…”.
- Click Preview to see an example.
- Go to an order that is already assigned to a last mile manifest.
- Preview the label – the new “Schedule Date” field will be displayed.
- Tag‑Along Orders: Scheduling, Movement & Notifications
- We’re extending tag‑along validations to scheduling. Only the parent order can be scheduled; followers automatically mirror the parent’s assignment (same manifest and stop), move with the parent, and are removed when the parent is removed. Notifications and charges apply to the parent only. Relationships remain one‑way, single‑level.
- Key Enhancements
- Parent‑Only Scheduling – Followers cannot be scheduled directly; attempts return error message.
- Auto‑Follow on Schedule/Move/Remove – When a parent is scheduled, followers are placed on the same manifest and stop. Moving or removing the parent moves/removes all followers accordingly.
- Notifications Scoped to Parent – Lasso, scheduling confirmation, time‑frame confirmation, and delivery confirmation are sent once to the parent only (no duplicate sends to followers).
- Charges Scoped to Parent – For linked orders, charges apply once to the parent at the account level. (We can consider optional separate‑charge support on request.)
- Unlinking Scheduled Orders – Unlinking a follower prompts a message popup; the follower is removed from the manifest and reverted to RTBS. The parent remains scheduled.
- Pre‑Schedule Validation (all must pass)
- Parent and followers are RTBS.
- Parent and followers have no charges due (prepaid).
- All linked orders’ shippers are not frozen.
- Enough truck capacity (cube/items/stops).
- Linking to an Already‑Scheduled Parent – Allowed only if the follower is RTBS, not frozen, and capacity allows; otherwise return the appropriate error messages.
- Relationship Rules – A parent can have multiple followers; a follower has one parent. Single level only (no “grandparent” chains). One‑way: parent → follower.
- Interim Safeguard – Keep the existing validation that blocks adding a follower to a scheduled parent until the full rollout is complete.
Bug Fixes
- Shared User Email Removal Logic Corrected
- We’ve resolved an issue that caused email addresses associated with multiple shipper accounts to behave inconsistently when being removed, impacting user management and visibility.
- Issue Summary
- The same email address could be linked to multiple shipper accounts, but removing it from one account would not actually remove the user.
- What’s Been Fixed
- User Disassociation Logic Updated
- Removing a user from a specific shipper account now correctly removes that user from that account only, without affecting their presence in other accounts.
- Data Consistency Restored
- The system now respects account-level user scoping and handles shared email addresses appropriately.
- Expected Behavior
- Deleting a user from one account removes access only from that account.
- Shared emails can now be independently managed per account.
- User Disassociation Logic Updated
- Inactive Regions No Longer Available for Manifest Destination Selection
- A bug allowing users to select inactive regions as destination or origin in various manifest creation flows has been resolved to prevent routing conflicts and data inconsistencies.
- Issue Summary
- Inactive regions were incorrectly available for selection in the Destination Region and Origin Region drop-downs when creating new manifests.
- This allowed freight to be assigned to inactive hubs, potentially causing manifest failures or logistical misalignment.
- What’s Been Fixed
- Inactive Regions Filtered
- Inactive regions are now excluded from the dropdown selectors in the New Manifest creation process.
- Scope of Fix
- Linehaul → Inbound → Destination Region
- Linehaul → Outbound → Origin & Destination Region
- Inventory → Destination Region
- Last Mile → New Manifest → Origin Region
- Expected Behavior
- Only active regions are available for selection.
- No impact to existing region filters across the system
- Inactive Regions Filtered