Flow Name: Chargent Order: Update Transaction as Recurrent¶

Last Updated: 2025-05-30 Source Code: Chargent_Order_Update_Transaction_as_Recurrent.flow-meta.xml

API Name: Chargent_Order_Update_Transaction_as_Recurrent Status: Active Type: Custom Trigger: ChargentTransaction creation (after save) with async processing

Business Purpose¶

Manages recurring transaction status by marking transactions as recurring when the related ChargentOrder has recurring payment status, and updates Account-level recurring flags to maintain consistency across the subscription system.

Process Flow¶

1. Async Processing: Uses async after commit for performance
2. Recurring Status Check: Verifies if ChargentOrder has "Recurring" payment status but transaction is not marked as recurring
3. Transaction Update: Marks transaction as recurring (ChargentOrders__Recurring__c = true)
4. Account Lookup: Retrieves related Account that is marked as recurring (isRecurring__c = true)
5. Account Status Update: Sets Account isRecurring__c = false to indicate processing completed
6. Error Handling: Includes fault paths for both transaction and account updates

flowchart TD
    Start([Start: ChargentTransaction Create<br/>After Save Async]) --> Check{ChargentOrder<br/>Payment Status = Recurring<br/>AND<br/>Transaction Not Recurring?}

    Check -->|No| End([End])
    Check -->|Yes| UpdateTrans[Update Transaction:<br/>Recurring__c = TRUE]

    UpdateTrans --> TransError{Update<br/>Success?}
    TransError -->|No| Error1[Display Error:<br/>Transaction Update Failed]
    TransError -->|Yes| GetAccount[Get Related Account<br/>where isRecurring__c = TRUE]

    GetAccount --> UpdateAcct[Update Account:<br/>isRecurring__c = FALSE]

    UpdateAcct --> AcctError{Update<br/>Success?}
    AcctError -->|No| Error2[Display Error:<br/>Account Update Failed]
    AcctError -->|Yes| End

    Error1 --> End
    Error2 --> End

    style Start fill:#e1f5ff
    style Check fill:#fff4e1
    style UpdateTrans fill:#ffe1e1
    style TransError fill:#fff4e1
    style GetAccount fill:#f0e1ff
    style UpdateAcct fill:#ffe1e1
    style AcctError fill:#fff4e1
    style Error1 fill:#ffcccc
    style Error2 fill:#ffcccc
    style End fill:#e1f5ff

Key Business Rules¶

• Only processes when ChargentOrder payment status is "Recurring" and transaction is not yet marked as recurring
• Requires Account to be marked as recurring before processing
• Clears Account recurring flag after successful processing
• Uses async processing to avoid blocking main transaction flow
• Comprehensive error handling with custom error messages

Dependencies¶

• ChargentOrders__Transaction__c with ChargentOrders__Recurring__c field
• ChargentOrders__ChargentOrder__c with ChargentOrders__Payment_Status__c field
• Account object with isRecurring__c field
• Proper relationships between Transaction → ChargentOrder → Account

Changes¶

No specific PR references noted in flow description.

⚠️ Pre-Go-Live Concerns¶

CRITICAL - Fix Before Go-Live¶

• No critical issues identified - good error handling implemented

HIGH - Address Soon After Go-Live¶

• Account status clearing logic may create confusion if multiple transactions processing
• Missing logging for successful vs failed processing attempts

MEDIUM - Future Enhancement¶

• Consider using platform events instead of Account flag approach
• Add audit trail for recurring status changes
• Implement retry logic for failed updates

LOW - Monitor¶

• Monitor error rates and types from fault paths
• Validate Account status consistency
• Track async processing timing and performance

Maintenance Notes¶

Well-structured flow with proper error handling. The Account flag approach for coordination may be complex to debug. Consider monitoring the error paths and evaluating alternative coordination mechanisms for better scalability.