Trigger Name: I2C_ProcessOrderReturnTrigger¶

Last Updated: 2025-10-22 Source Code: https://github.com/AANP-IT/I2C.Salesforce.Metadata/blob/STAGING/force-app/main/default/triggers/I2C_ProcessOrderReturnTrigger.trigger

API Name: I2C_ProcessOrderReturnTrigger Object: Process_Order_Refund__e (Platform Event) Pattern: Framework Pattern (TriggerHandler)

Business Purpose¶

This trigger responds to Process_Order_Refund__e platform events to initiate automated refund processing workflows. It provides event-driven architecture for order refunds, enabling decoupled, scalable processing of refund requests from various sources (UI actions, integrations, batch processes) without tight coupling to the triggering system.

Trigger Events¶

This trigger fires on the following events: - ☐ Before Insert - ☐ Before Update - ☐ Before Delete - ☑️ After Insert (Platform Events only support after insert) - ☐ After Update - ☐ After Delete - ☐ After Undelete

Trigger Handler¶

Handler Class: I2C_ProcessOrderReturnTriggerHandler.cls Pattern: Framework Pattern - Extends TriggerHandler base class Entry Point: Handler instantiation with execute() method

trigger I2C_ProcessOrderReturnTrigger on Process_Order_Refund__e (after insert) {
    new I2C_ProcessOrderReturnTriggerHandler().execute();
}

Process Flow by Event¶

After Insert¶

Purpose: Capture refund event and initiate refund processing workflow

Business Logic: 1. Extract OrderId__c values from all Process_Order_Refund__e events 2. Collect unique Order IDs into a Set 3. Call I2C_RefundOrder.processOrders() with Order IDs 4. Refund processing logic handles querying orders and initiating refunds

Methods Called: - I2C_ProcessOrderReturnTriggerHandler.afterInsert(Map<Id, SObject> newRecordsMap) (inherited from TriggerHandler) - I2C_RefundOrder.processOrders(Set<Id> orderIds)

Related Records Processed: - Order records identified by OrderId__c in platform events - Downstream payment/refund records (handled by I2C_RefundOrder)

Key Business Rules¶

Validation Rules¶

Platform events must contain valid OrderId__c values
Refund processing logic (in I2C_RefundOrder) likely validates order eligibility

Field Updates¶

No direct field updates in trigger (processing handled by I2C_RefundOrder)

Orders queried and processed for refunds
Payment/transaction records likely created or updated by refund logic

Bulkification & Governor Limits¶

Bulkified: Yes (Platform Events) Max Records Handled: Platform Events can handle up to 2,000 events per transaction SOQL Queries: 0 in trigger (queries in I2C_RefundOrder class) DML Operations: 0 in trigger (DML in refund processing logic)

Bulkification Strategy¶

Platform Events inherently support bulk publishing
Trigger collects all Order IDs from all events in batch
Single call to I2C_RefundOrder.processOrders() with all Order IDs
Refund processing handles multiple orders in single transaction

Governor Limit Considerations¶

Platform Event Limits: 2,000 events per transaction, 250,000 per 24 hours
SOQL: Queries happen in I2C_RefundOrder (not in trigger)
DML: DML operations happen in refund processing logic
Async Limits: May use Queueable/Future methods for payment processing

Recursion Prevention¶

Strategy: Platform Events cannot trigger themselves

Implementation: - Platform Events are fire-and-forget - Events do not re-trigger on DML operations - Natural protection from recursion due to event architecture

Scenarios: - No recursion risk with platform events - Event processing is one-way (event -> processing -> completion)

Execution Order & Dependencies¶

Order of Execution Impact¶

Platform Events fire after the publishing transaction commits
Processing happens asynchronously after event delivery
Event triggers run in separate transaction from publishing transaction

Dependent Triggers¶

OrderTrigger: May fire when orders are updated during refund processing
Risk: Minimal - event processing is decoupled from order triggers

Dependent Processes¶

I2C_RefundOrder: Core refund processing logic
I2C_QueueableRefund: Likely handles async payment gateway calls
Payment Gateway Integration: External system for actual refund execution

Error Handling¶

Strategy: Platform Event error handling with retry

User Experience: - Success: Event processed, refund initiated - Event Delivery Failure: Salesforce automatically retries event delivery - Processing Error: Error occurs in I2C_RefundOrder logic, event still acknowledged

Logging: - Platform Events provide built-in event delivery monitoring - Application-level logging should be in I2C_RefundOrder class - Event Bus monitoring available in Event Manager

Rollback Behavior: - Event publishing transaction separate from processing transaction - Processing errors don't rollback event publication - Failed processing should be logged and may require manual retry

Dependencies¶

Apex Classes¶

I2C_ProcessOrderReturnTriggerHandler: Handler extending TriggerHandler
TriggerHandler: Base framework class
I2C_RefundOrder: Core refund processing logic
I2C_QueueableRefund: Async payment processing (likely)

Salesforce Objects¶

Process_Order_Refund__e: Platform Event object
Order: Standard object being processed
Payment/Transaction objects (implementation-specific)

Custom Settings/Metadata¶

Platform Event Channel Settings (Salesforce managed)

External Systems¶

Payment Gateway/Processor for actual refund execution

Testing¶

Test Class: I2C_ProcessOrderReturnTriggerHandler likely has corresponding test class Coverage: Unknown

Test Scenarios: - Single event publication and processing - Bulk event publication (multiple events) - Invalid Order IDs in events - Event processing with refund logic errors - Platform Event delivery and acknowledgment - Test.getEventBus().deliver() for event testing

Performance Considerations¶

Average Execution Time: Fast (trigger only routes to handler) Max Records Processed: Up to 2,000 events per transaction Async Processing: Yes - Platform Events are inherently async

Optimization Opportunities: - Already optimized with platform event architecture - Ensure I2C_RefundOrder handles bulk processing efficiently - Monitor Event Bus delivery metrics - Consider event batching if high volume

Changes & History¶

Author: I2C development team
Pattern: Modern event-driven architecture using Platform Events and TriggerHandler framework

Pre-Go-Live Concerns¶

CRITICAL - Fix Before Go-Live¶

No Error Handling in Trigger: Trigger assumes I2C_RefundOrder will handle all errors. Need try-catch wrapper
Event Idempotency: No mechanism to prevent duplicate refund processing if same event delivered multiple times
Order ID Validation: No validation that OrderId__c values are valid before processing

HIGH - Address Soon After Go-Live¶

No Logging in Trigger: Add logging of event receipt and Order IDs being processed
Event Monitoring: Implement monitoring dashboard for event processing success/failure rates
Error Notifications: Set up alerts for refund processing failures
Event Replay Strategy: Document how to replay events in case of processing failures

MEDIUM - Future Enhancement¶

Event Deduplication: Implement deduplication logic using event replay ID or custom tracking
Batch Processing: Consider batching for extremely high volumes
Event Archiving: Strategy for long-term event history and audit
Rate Limiting: Protection against event flood scenarios

LOW - Monitor¶

Event Bus Limits: Monitor daily and hourly platform event limits
Processing Latency: Track time between event publication and processing completion
Event Delivery Metrics: Use Event Manager to monitor delivery rates

Maintenance Notes¶

Complexity: Low-Medium Recommended Review Schedule: Quarterly (or when refund logic changes)

Key Maintainer Notes: - This trigger uses Platform Events for event-driven architecture - very different from standard triggers - Platform Events are asynchronous and transactional - event published AFTER transaction commits - Testing Platform Events requires Test.getEventBus().deliver() method - Platform Events have separate governor limits from standard Apex - Event delivery is guaranteed but may be delayed under high load - Events cannot be rolled back once published - Use Event Monitor in Setup to troubleshoot delivery issues

Deactivation Instructions: Platform Event triggers cannot be easily disabled in production. Options:

Modify trigger to check custom metadata:

trigger I2C_ProcessOrderReturnTrigger on Process_Order_Refund__e (after insert) {
    if (TriggerSettings__mdt.getInstance('ProcessOrderReturn')?.Disabled__c == true) {
        return;
    }
    new I2C_ProcessOrderReturnTriggerHandler().execute();
}

Stop publishing events at the source (preferred for temporary disable)

Event Replay Considerations: - Platform Events support event replay using replay ID - Replay window is 72 hours (3 days) - Implement idempotency to handle replay scenarios safely - Test replay scenarios in sandbox before go-live