Skip to content

Flow Name: I2C Refund Transaction Send Notice

Last Updated: 2025-10-22 Source Code: I2C_Refund_Transaction_Send_Notice.flow-meta.xml

API Name: I2C_Refund_Transaction_Send_Notice Status: Active Type: Custom Trigger: Record-Triggered (Chargent Transaction - After Save, with 1-minute scheduled delay)

Business Purpose

This flow automatically notifies customers via email when their orders have been refunded or voided, ensuring transparent communication about refund processing and maintaining customer trust.

Process Flow

  1. Transaction Created/Updated: Chargent Transaction with refund or void is saved
  2. 1-Minute Delay: Scheduled path waits to ensure all data relationships are established
  3. Data Retrieval Chain:
  4. Get Chargent Order (includes Account and PersonContact)
  5. Get Standard Order (provides context for email template)
  6. Get Email Template ("Refund_Issued")
  7. Send Email: Delivers refund notification to customer
  8. Error Handling: If email fails, updates transaction description field with error message
📊 Click to view Process Flow Diagram 
flowchart TD
    Start([Start: Refund/Void Transaction]) --> Wait[Wait 1 Minute]
    Wait --> GetChargent[Get Chargent Order]
    GetChargent --> GetOrder[Get Standard Order]
    GetOrder --> GetTemplate[Get Email Template]

    GetTemplate --> SendEmail[Send Refund Email]
    SendEmail --> Success{Email Sent?}

    Success -->|Yes| End([End])
    Success -->|No| AddError[Add Error to Transaction Description]
    AddError --> End

    style Start fill:#e1f5ff
    style Wait fill:#fff4e1
    style SendEmail fill:#ffe1e1
    style Success fill:#fff4e1
    style AddError fill:#ffe1e1
    style End fill:#e1f5ff

Key Business Rules

  • Refund Detection: Triggers on Refund type with negative amount OR Void type (any amount)
  • Change-Based: Only fires when Order__c field changes AND is not blank
  • Scheduled Execution: 1-minute delay after Gateway Date ensures transaction processing is complete
  • Non-Blocking Errors: Email failures don't prevent refund processing; error is logged to description field
  • Email Logging: All sent emails are logged to activity timeline for audit purposes

Dependencies

  • ChargentOrders Package: Transaction and ChargentOrder objects
  • Standard Objects: Order, Account (Person Account), Contact
  • Email Template: "Refund_Issued" (DeveloperName)
  • Org-Wide Email Address: noreply@aanp.org

Changes

No specific PR references found in the flow description or comments.

Pre-Go-Live Concerns

CRITICAL - Fix Before Go-Live

  • None identified

HIGH - Address Soon After Go-Live

  • Missing Null Check: No validation that PersonContactId exists on Account before sending email
  • Email Template Dependency: Flow fails silently if "Refund_Issued" template is deleted or renamed

MEDIUM - Future Enhancement

  • Error Notification: No alert sent to admins when email delivery fails
  • Retry Logic: No automatic retry mechanism for failed email sends
  • Hardcoded Email: Org-wide email address is hardcoded; consider using custom metadata

LOW - Monitor

  • 1-Minute Delay: May be too long or too short depending on transaction processing speed
  • Multiple Triggers: If Order__c changes multiple times, multiple emails could be sent

Maintenance Notes

Complexity: Low - Simple email notification flow with straightforward error handling

Review Schedule: Annual review sufficient for this notification flow

Testing Requirements: - Test with refund transactions - Test with void transactions - Verify email template merge fields populate correctly - Test error handling when email delivery fails - Verify 1-minute delay timing is appropriate