Grasshopper 3.24.33 Release Notes
Features: Lasso for Return Orders (Pickup Returns)
Overview
Grasshopper’s Lasso workflow historically supported only delivery orders, leaving operations teams without an efficient way to schedule pickup return orders, including disposition pickups and return-to-vendor scenarios.
Partners requested the ability to trigger both manual Lasso and auto Lasso for return pickups, enabling consistent scheduling workflows and operational predictability.
This enhancement introduces full Lasso support for pickup return orders, allowing users to schedule customer-originating return pickups with the same simplicity and automation available for delivery Lasso.
Key Enhancements
1. Manual Lasso for Pickup Returns
● Added a Manual Lasso (key icon) to the pickup scheduling section for return orders, matching the delivery Lasso UI pattern.
● The icon appears beside each item; however:
○ Selecting the icon triggers a pickup request for all items associated with the return order.
○ Partial pickups are not allowed — all items must be scheduled together.
● The Lasso popup and confirmation flow match the delivery Lasso experience but are adapted for pickup logic.
● Lasso uses the pickup address, not the delivery address.
2. Auto Lasso for Pickup Returns
● Updated the Lasso plugin query to include Pending Return orders that are eligible for scheduling.
● Auto Lasso now:
○ Sends RTBS as a pickup request rather than a delivery.
○ Correctly uses pickup contact information, fixing a previous limitation where only delivery customer details were used.
● Ensures that return pickups are scheduled automatically when operational conditions are met.
3. Operational Guidelines
● Pickup returns always originate from one customer address.
● When multiple items exist within the return order:
○ They must be picked up together in a single scheduled pickup.
● Manual and Auto Lasso apply only when the order status is Pending Return.
Out of Scope
The Pickup orders will be handled separately when it comes to these areas, i.e the delivery messages and tracking will still serve the pickup orders as well:
● Emails
● SMS notifications
● Robocalls
● Tracking page updates
Hub Daily Inbound Thresholds
Overview
Hubs have physical and operational limits on how much inbound volume they can process on any given day—such as the maximum number of manifests, total cube, or total pieces they can unload.
To support future alerting and insights, Grasshopper is introducing configurable Hub Daily Inbound Thresholds, allowing each hub to define its operational capacity metrics.
These values will serve as foundational inputs for upcoming monitoring and alerting capabilities, enabling proactive notification when a hub risks exceeding its daily operational limits.
Key Enhancements
1. New Inbound Threshold Properties in Warehouse Policy
A new configuration section is added under:
Region → Warehousing and Storage → Warehouse Policy
Hubs can now define the following optional daily thresholds:
● Daily Max Inbound Manifests
● Daily Max Inbound Cube
● Daily Max Inbound Pieces
These thresholds act as general capacity definitions that future insights and alerting engines will reference.
2. Input & Validation Rules
To ensure clean and consistent data entry, the following input rules apply: ● Accepts only numbers and a decimal point.
● Only positive numbers are allowed.
● If a number contains more than 4 decimal places, it is automatically truncated (not rounded).
● All fields are optional and may be left blank.
These rules ensure fields remain structurally valid and ready for downstream processing.
3. Error Handling & User Feedback
When saving the Warehouse Policy settings:
● If any field contains invalid input, a Swal popup appears with the message: “Some fields have invalid input. Please check and try again.”
● Invalid fields receive a red border to visually guide the user toward corrections. This ensures proper validation and prevents accidental saving of corrupt values.
Driver App – Waiver Flow Enhancement
Overview
The Waiver functionality in the Driver App allows customers to acknowledge responsibility and waive compensation claims related to property or product damage.
While the feature is critical for operational protection, its current placement on the stop page and the fragmented signing process create friction for drivers and an inconsistent user experience.
This enhancement restructures the Waiver into a streamlined, in-flow experience during POD (Proof of Delivery) or pickup-return confirmation.
The updated flow aligns with driver behavior, reduces cognitive load, and ensures that Waiver capture, OTP validation, and signature inputs occur at the correct moment within the delivery or pickup process.
The enhancement covers Home Delivery (HD) and Pickup Returns from customers. Vendor pickup workflows are out of scope.
Key Enhancements
1. Waiver Moved Into the POD Flow
● The Waiver button is removed from the stop page and now appears only inside the driver’s POD workflow.
● Drivers now decide between:
○ rejecting due to “not fit,” or
○ requesting customer Waiver signing.
● This aligns the Waiver action with the exact moment drivers capture final delivery/pickup confirmation.
2. Integrated OTP + Consignee Validation
● OTP is an optional configurable step
● Before signing the Waiver, drivers must collect:
○ Customer OTP, when advanced settings require it.
○ Consignee name, matching today’s signature requirements.
● OTP + consignee name are captured once per stop.
○ If they were completed during Waiver signing, the app will skip these steps when proceeding to final signature.
3. Driver + Customer Interaction Improvements
● After the customer enters OTP and consignee name, the device returns to the driver in a new screen designed for:
○ capturing Waiver photos, and
○ completing the Waiver with a single “Done” action.
● Waiver action becomes single-use:
○ After completion, the Waiver icon becomes marked as “✓” and is disabled.
4. Updated Messaging and Tracking
● A new tracking event is added:
“Delivery/Pickup Waiver has been filled by the consignee.”
● Waiver disclaimers updated to replace all occurrences of “delivery” with “Delivery/Pickup” to accurately reflect the expanded workflow.
5. Post-Waiver Logic Adjustments
● Once Waiver is completed:
○ The “damage to residence” option is blocked in Customer POD.
○ Consignee name is pre-populated for final signature.
○ OTP is not required a second time.
Driver App – Support for Mixed Tag-Along Stops (Delivery, Pickup Return & Service Tickets)
Overview
Today, drivers may encounter stops that contain a combination of delivery orders, pickup return orders, and service tickets.
In the existing workflow, these mixed “tag-along” scenarios are difficult to execute because all items are grouped into a single POD flow, despite the operational differences between deliveries, pickups, and service tasks.
This enhancement introduces full support for mixed-type stops, ensuring each order type receives its own structured POD workflow and final POD file. Drivers can now handle complex stops clearly, sequentially, and in any order they choose, without losing visibility or control.
The enhanced design improves accuracy, compliance, and user experience by clearly separating actions, signatures, service levels, and POD outputs per order type.
Key Enhancements
1. Updated Stop Labeling for Mixed Tag-Along Stops
Stop labels now reflect the mix of order types present at the stop:
● “D” — Delivery only or Delivery + Service Ticket
● “P” — Pickup Return only or Pickup Return + Service Ticket
● “S” — Service Ticket only
● “D&P” — Delivery + Pickup Return (with or without Service Ticket)
This provides instant visibility to drivers and support staff regarding the stop’s composition.
2. Separate POD Flows Per Order Type
When the driver starts the POD process, items are organized into three clear categories: ● Delivery
● Pickup
● Service
Drivers may choose any category to start with and complete them in any order.
Each category uses its own POD flow, including signature, photos, notes, waiver, and disposition logic.
3. Enhanced Consignee POD with Five Sections
After the driver completes all orders and service items for the stop, the app transitions to the Consignee POD screen.
The consignee now sees five structured sections:
1. Delivery items
2. Pickup items
3. Services
4. Damage to property
5. Others
This streamlined structure strengthens transparency and supports accurate customer acknowledgement.
4. Embedded Services Support
Delivery and pickup return orders may include embedded service items. These appear under the corresponding delivery or pickup flow and:
● inherit the parent order’s POD flow
● appear in the individual order’s POD file
● are shown at item level so the driver can follow the required service level
Each order may have a different service level, and the driver app highlights this per item.
5. Independent Completion/Rejection Per Order
Orders within a single stop may have different outcomes:
● Some may be completed
● Others may be rejected
The stop supports mixed-order results without forcing the same status across all orders. If any order in the stop fails, the entire stop is marked as:
New Status: “Partial Delivered”
This status signals that at least one action succeeded and one failed within the same tag-along stop.
6. POD File Generation Per Order
Each order type—delivery, pickup return, service ticket—receives a separate POD file, including:
● Relevant items
● Services
● Signatures
● Waiver screenshots
● Photos
● Notes
This improves auditing, customer communication, and integration accuracy for partner systems.
7. Unified Waiver Flow
● Waiver is available throughout the entire POD sequence.
● Waiver is completed once per stop, even in mixed tag-along scenarios. ● OTP and consignee name (based on advanced settings) are captured only once.
● If the consignee authentication occurred during the Waiver, it is not requested again during delivery/pickup signatures.
Out of Scope
● RMA workflows
● Haul Away workflows
Driver App – Dynamic Disclaimer Engine
Overview
Disclaimers are short, legally meaningful statements that customers review and sign as part of the POD (Proof of Delivery) process.
Today, disclaimers are static and cannot adapt to the specific operational context of the stop—such as whether the order involves unpacking, multiple orders, a pickup return, or a damage scenario.
This enhancement introduces a Dynamic Disclaimer Engine in the Driver App, enabling Grasshopper to construct the exact disclaimer text for each order based on rules, service levels, and stop outcomes.
The engine ensures that customers always receive accurate, scenario-appropriate language, improving compliance, consistency, and customer understanding.
Key Enhancements
1. Centralized Disclaimer Clause Library
● A structured pool of reusable clauses is created to serve as the building blocks for generating complete disclaimers.
● Clauses include:
○ Standard delivery statements
○ Service-level–specific text (e.g., unpacked vs. packaged)
○ Pickup return disclaimers
○ Multi-order stop disclaimers
○ Damage-related disclaimers (product, residence, other)
○ Additional clauses for satisfaction, refusal, or partial completion scenarios
● All text is centrally managed, making it easier to update and maintain compliance across all markets.
2. Dynamic Assembly Based on Operational Logic
The Driver App now assembles the correct disclaimer at runtime, using the following decision factors:
1.Order Type
○ Determines whether the stop uses a full POD or short POD.
○ For example:
■ Delivery → full POD
■ Pickup return → short POD (unless services added)
2.Service Level
○ Determines unpacking expectations and impacts disclaimer text.
○ Examples:
■ “White glove” includes unboxing and placement
■ “Threshold only” leaves items in packaging
○ The disclaimer dynamically reflects what was or was not performed.
3.Single vs. Multi-Order Stop
○ Multi-order stops adjust disclaimers to reflect responsibility across all included orders.
○ Clauses adapt based on delivery + pickup combinations, embedded service items, etc.
4.Delivery / Pickup Scenario Outcome
○ The actual result of the stop modifies the disclaimer:
■ Full satisfaction
■ Product damage
■ Residence damage
■ Partial success
■ Other issues reported
○ Relevant clauses are appended automatically.
The engine ensures the final disclaimer is accurate, contextual, and legally aligned with the actions performed.
3. Order-Specific Disclaimer Construction
● Each individual order receives its own dynamically generated disclaimer, even within a multi-order stop.
● Disclaimer text is displayed to the customer within the POD flow and is captured with: ○ Signature
○ Waiver (if applicable)
○ Photos and notes
● This ensures each order’s POD file includes the correct disclaimer for record-keeping and partner integrations.
4.POD Output Integration
● The generated disclaimer is stored and associated with the order’s POD package.
● POD PDFs will incorporate the disclaimer text (enhancements to PDF templates may follow in separate tasks).
Out of Scope
● Final POD PDF template refinements (handled under separate tasks if needed) ● Waiver logic (covered in another enhancement)
Driver App – Updated Messaging When ETA Is Not Available
Overview
In certain situations, the Driver App is unable to determine the Estimated Time of Arrival (ETA)—for example, when GPS is temporarily unavailable or location permissions are restricted. Previously, the app displayed a system-style error message that interrupted the flow and created confusion for drivers attempting to notify customers.
This enhancement replaces the error message with a clear, generic, user-friendly notification, allowing drivers to proceed smoothly and continue with their route without requiring ETA input.
The new message provides customers with relevant context while eliminating the need for manual ETA scrolling or error acknowledgment.
Key Enhancements
1. New Generic Popup When ETA Cannot Be Determined
● The old GPS/ETA error message is replaced with a simplified, non-blocking popup. ● New popup text:
“Your next stop is <customer name> at <street no, street, city>. Please notify them with your estimated time of arrival.”
● The popup provides:
○ Confirmation of the customer’s identity
○ Full address information
○ A clear instruction for the driver to notify the customer manually
This reduces friction and avoids confusion caused by the previous error.
2. Removal of the ETA Scroll Input
● When ETA is unavailable:
○ The ETA scrolling selector is removed.
○ Drivers are no longer required to manually select an ETA value.
● All other workflow components remain unchanged.
3. Updated SMS Template When User Presses “SMS”
If the driver chooses to notify the customer via SMS from this screen, the Driver App now sends:
“Hello, your order is the next stop on the route. Your driver <driver_name> is on the way.”
● Message is concise, friendly, and accurate even without calculated ETA.
● This improves clarity for customers while minimizing confusion when GPS data is missing.
Defect Fixes
Driver App – Verification Process Reliability Improvement
Overview
Several partners reported cases where the Driver App verification process did not complete, preventing drivers from accessing their assigned routes.
The issue occurred intermittently across multiple regions,and required manual override as the only available workaround.
This enhancement improves the stability and reliability of the Driver App’s verification logic, ensuring drivers can consistently authenticate and access their routes without operational delays.
Key Fixes
1. Strengthened Verification Flow State Handling
● Added additional guard conditions to prevent the verification sequence from entering an incomplete or stalled state.
● Improved synchronization between driver authentication, device validation, and route assignment loading.
2. Improved Session Initialization Logic
● Updated the logic responsible for preparing route data and driver permissions immediately following verification.
● Prevented previously observed edge cases where the app waited indefinitely for an initialization response.
3. Fail-Safe Recovery Path
● Introduced a fallback mechanism allowing the verification workflow to retry under certain conditions without requiring manual override.
● Ensures drivers regain access faster when transient data or connectivity issues occur. 4. Expanded Logging & Diagnostics
● Added enhanced telemetry around:
○ session startup
○ verification checkpoints
○ manifest assignment loading
● These improvements enable better monitoring and faster identification of anomalies in future releases.
Bug Fix: Filters Disappear After Adding Orders to Manifests
Overview
Users reported that applying filters in the Orders page does not persist after adding selected orders to a manifest.
After completing the “Add to Manifest” action and returning to the Orders grid, all applied filters disappear—except for the “More” dropdown—forcing users to reapply their filters and disrupting workflow efficiency.
This behavior was confirmed and reproduced based on the report from Cody (Deliveright), who noted that Order Search Option filters were inconsistently disappearing after order-level actions.
Actual Behavior
● User applies filters on the Orders page.
● User selects multiple orders and adds them to a manifest.
● After submitting and returning to the Orders grid:
○ All filters are cleared, except for “More”.
Expected Behavior
● Filters should remain persistent, regardless of the action taken on orders.
● Returning to the Orders page should maintain the user’s previously applied filtering context.
Key Fixes
1. Filter Persistence Restored
Ensured that the Orders grid preserves all active filters after completing the “Add to Manifest” workflow.
2. Corrected Grid State Handling
Updated internal page state logic to prevent unintended reset of filter parameters when navigating back from manifest actions.
3.Stability Improvements for Order Search Options
Resolved the issue causing certain filter categories (including advanced filters) to disappear or reset unexpectedly.
4. Consistent UI Behavior Across All Order Actions
All order-level actions—including Add to Manifest—now return users to a fully intact filtered view.