Skip to content

Flow Name: [I2C] Refund Order: Retry Utility

Last Updated: 2025-10-16 Source Code: I2C_Refund_Order_Retry_Utility.flow-meta.xml

API Name: I2C_Refund_Order_Retry_Utility Status: Active Type: Custom Trigger: Screen flow (launched from refund Order record page)

Business Purpose

Provides a screen flow interface for handling refund orders, allowing users to retry failed refunds and view refund status. Calculates refunded amounts from transaction history and triggers refund retry processing through platform events.

Process Flow

  1. Get Order: Retrieves the Order record details
  2. Get Transactions: Finds all approved transactions related to the order
  3. Loop Transactions: Iterates through each transaction to:
  4. Add refund amounts to running total
  5. Subtract void amounts from running total
  6. Refund Status Decision: Determines refund status:
  7. Data Integrity Error: Order has negative total but no RelatedOrderId (not a proper refund order)
  8. Incomplete Refund: Refunded amount is less than order total - shows retry option
  9. Complete Refund: Full amount already refunded - shows completion message
  10. Platform Event: Creates Process_Order_Refund__e event to trigger retry processing
  11. Wait Screen: Shows user message to wait for processing completion
📊 Click to view Process Flow Diagram 
flowchart TD
    Start([Start: Screen flow (launched from refund Order record page)]) --> Screen[Display Screen:<br/>User Input Required]

    Screen --> UserInput[User Enters Data]
    UserInput --> Process[Process Input]
    Process --> Action[Execute Action]
    Action --> End([End])

    style Start fill:#e1f5ff
    style Screen fill:#fff4e1
    style UserInput fill:#e1ffe1
    style Process fill:#ffe1e1
    style Action fill:#ffe1e1
    style End fill:#e1f5ff

Key Business Rules

  • Only processes orders with approved transactions
  • Calculates net refunded amount (refunds minus voids)
  • Validates order is actually a refund order (has RelatedOrderId)
  • Uses platform events for asynchronous refund retry processing
  • Prevents retries when full refund already processed

Dependencies

  • Order object with RelatedOrderId field
  • ChargentOrders__Transaction__c object
  • Process_Order_Refund__e platform event
  • Proper refund order structure (negative total with RelatedOrderId)

Changes

None explicitly noted in the flow

⚠️ Pre-Go-Live Concerns

CRITICAL - Fix Before Go-Live

  • Data integrity validation: Shows error for orders with negative totals but no RelatedOrderId - this could indicate deeper data issues
  • Platform event reliability: Relies on platform event processing for actual refund retry - failure could leave orders in limbo
  • No timeout handling: User told to "wait a few minutes" but no automatic status updates

HIGH - Address Soon After Go-Live

  • Limited retry logic: No limit on number of retry attempts or cooling-off period
  • No admin notification: Failed retries don't alert administrators
  • Manual refresh required: Users must manually refresh to see updated status

MEDIUM - Future Enhancement

  • No audit trail: Doesn't track who initiated retry or when
  • Limited error details: Doesn't show why original refund failed
  • No batch processing: Handles one order at a time

LOW - Monitor

  • User experience: "Wait and refresh" approach could be improved with real-time updates
  • Transaction type coverage: Only handles Refund and Void types - other transaction types ignored

Maintenance Notes

Complexity: Medium - Involves transaction calculations and platform event processing. Monitor platform event processing performance and success rates. Review if refund retry failures increase or if users report issues with the wait/refresh process.