DATE:
AUTHOR:
Dutchie Product Team
TABLE OF CONTENTS:
    Dutchie POS

    Dutchie POS: View email marketing DNS records in Backoffice, ID scanning enhancements, audit changes made to segments; improved point boost tracking, and more

    DATE:
    AUTHOR: Dutchie Product Team
    TABLE OF CONTENTS:

      Projected release dates: 8/24/26-8/27/26. Subject to change.

      Enhancements

      Loyalty & Marketing

      View email marketing sender DNS records directly in Dutchie Backoffice. A new read-only Senders tab under Settings > Integrations > Email Marketing will display all DNS record details (DKIM, SPF, and branded link records) needed to configure your domain for email marketing deliverability.

      • One-click copy: Select Copy DNS Records to copy all record details (Host, Type, Value) as a formatted table you can paste directly into an email or your domain provider's interface.

      • Read-only access: Client users with the Access Email Marketing permission enabled can view sender DNS records. Editing or sending records is not available from this view.

      • Verify branded links: Users with the appropriate permissions can select Verify to re-pull the current DNS record information from the domain.

      • The previous "Send DNS Records" email form will be removed. DNS records will be accessed exclusively through the Senders tab described above.

      New segment history provides a clear audit trail for customer segments. You can now review when a segment was created or updated, who made the change, and what changed directly from the new History tab on the segment details page in Backoffice. This makes it easier to troubleshoot unexpected changes, verify marketing audience criteria, and maintain greater transparency around segment configuration.

      Point Boost activity is now easier to track across loyalty reporting. Point Boost transactions are now included in the loyalty ledger and Point Liability Dashboard, giving teams better visibility into points granted through automated workflows such as birthday bonuses or sign-up rewards. This helps marketers and administrators confirm that boosts were applied as expected, distinguish automated boosts from manual adjustments, and more accurately audit outstanding loyalty liability.

      Register

      We’re introducing enhancements to ID scanning at the Register to more reliably capture complete customer data and prevent duplicate profiles. This applies to Dutchie’s built-in ID scanning functionality and the VeriScan integration, though some additional configuration steps are requried for VeriScan. Learn more in the Help Center.

      Reports

      A new Summary Preorder Report helps teams review scheduled orders at a glance. The report provides an order-level summary of preorders, including key details such as order ID, customer, created date, transaction note, guestlist status, discounts, cart total, and scheduled date. This gives dispatch and operations teams a simpler way to verify routes and helps managers understand projected revenue by reviewing pending and completed preorder activity for a selected time period.

      Discounts

      Set a maximum number of Dutchie loyalty redemptions per transaction. Control how many loyalty rewards can be applied to a single sale to protect margins and keep discounting aligned with your store policy. Budtenders will see clear enforcement in the cart when the configured limit is reached, while retailers that want to allow unlimited redemptions can leave the setting blank. To set your limit, go to Marketing > Loyalty and enter a number in the Max # of redemptions per transaction field (Redemption method must be set to Apply loyalty as discounts to expose this field).

      Inventory

      Smart Tags automate inventory tagging based on product and package criteria. Retailers can create rules that automatically apply or remove inventory tags for items that match conditions such as expiration date, potency, brand, category, quantity, or sales activity. This reduces manual inventory work and makes it easier to power workflows like clearance discounts, outlet menus, fresh drops, and high-potency collections.

      Inventory receiving now shows product brand details where staff need them most. The Receive Inventory table includes a Brand column, and the Receive Package product dropdown now displays brand information alongside SKU and strain. This makes it easier for teams to distinguish similarly named products, reduce receiving errors, and process manifests or manual package entries more quickly.

      Compliance

      Dutchie now better protects Metrc compliance during inventory moves between licenses. The Back Office Move workflow prevents inventory from being silently moved to a location under a different Metrc license unless the proper affiliated-transfer process is used. This helps multi-license operators keep Dutchie and Metrc inventory records aligned while preserving normal same-license room moves.

      Payments

      Enhanced fraud protection for Pay by Bank transactions. We’re implementing automatic checks for customer identity details based on their driver’s license information (when available) during Pay by Bank checkout to help detect and block known repeat fraud actors before a transaction is completed. This added protection is active by default for locations using Pay by Bank and does not require any setup.

      If a transaction is declined, staff will see a standard Pay by Bank decline message and should offer the customer another payment option. To protect customer privacy and store operations, staff should not communicate fraud-specific details to the customer.

      Fixes

      We’re releasing fixes for the following issues:

      • Multi-location operators will soon be able to transfer inventory between sister stores without losing Metrc Retail ID QR code data. Previously, the Retail ID icon would disappear at the receiving location after an internal transfer, requiring manual relabeling. With this fix, package Retail ID data is automatically carried over upon receipt — no workarounds needed.

      • We’re resolving an issue where the Purchase Order Report could return no data for valid date ranges. Purchase order reporting now more reliably includes matching purchase order activity, helping teams review historical purchasing and receiving details without needing a manual export.

      • BI customer reporting will include addresses stored as secondary address book entries when the primary address is blank. This resolves cases where delivery orders or integrations populated an address in POS, but the customer appeared with a blank address in BI reports. Reports now use the customer’s most recent address book entry as a fallback and include an indicator when that fallback address is used.

      • We’re fixing an issue that prevents the Register's “Sync from Onfleet” action from appearing when Sync route sequence from Onfleet is enabled.

      • Recreational customer profiles will now use Driver’s License as the primary identification type. Recreational profile ID labels, edits, and uploads now save to the driver’s license fields instead of MMJ fields, while medical profiles continue to use MMJ ID information as expected. This helps ensure customer identification details are stored in the correct place for each profile type.

      • Loyalty points awarded to customers upon sign-up expire the following day, regardless of the configured expiration window (e.g., 365 days). Affected customers would see their sign-up bonus points removed by the automated morning expiry job within 24 hours of earning them. Points will now correctly expire in accordance with the loyalty program's configured expiration settings.

      • We’re resolving a display issue on the E-Commerce Offers page where discounts configured with a per-customer usage limit (e.g., "Limit 1 per customer") incorrectly displayed the message "Sorry, this special isn't available for recreational customers" even when the discount was properly configured for recreational customers in Dutchie POS. These discounts have been excluded from the Offers page eligible items view, as per-customer limits cannot be enforced in a guest checkout flow. The discount continues to apply correctly at checkout for logged-in customers. This is an architectural limitation of the guest checkout experience. Discounts with per-customer usage limits will not surface on the Offers page but remain functional in cart and at checkout for identified customers.

      TABLE OF CONTENTS:
        Powered by LaunchNotes