Trigger Name: OrderTrigger¶

Last Updated: 2025-10-22 (Created: 2024-06-26) Source Code: https://github.com/AANP-IT/I2C.Salesforce.Metadata/blob/STAGING/force-app/main/default/triggers/OrderTrigger.trigger

API Name: OrderTrigger Object: Order (Standard Salesforce Object) Pattern: Framework Pattern (TriggerHandler)

Business Purpose¶

This trigger handles all Order lifecycle events, specifically monitoring for order updates to process canceled order business logic. It ensures that when orders are updated, the CanceledOrderLogic class is invoked to handle downstream impacts such as membership/subscription status updates, refunds, and inventory adjustments.

Trigger Events¶

This trigger fires on the following events: - ☐ Before Insert - ☐ Before Update - ☐ Before Delete - ☑️ After Insert - ☑️ After Update - ☐ After Delete - ☐ After Undelete

Trigger Handler¶

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

trigger OrderTrigger on Order (after insert, after update) {
    new OrderTriggerHandler().execute();
}

Process Flow by Event¶

After Insert¶

Purpose: Currently no logic - placeholder for future insert processing

Business Logic: - Handler extends TriggerHandler but after insert method not overridden - Reserved for future order insert business logic

After Update¶

Purpose: Process order updates to handle canceled orders

Business Logic: 1. Compare old and new Order records 2. Detect status changes or other significant field updates 3. Route to CanceledOrderLogic.run() with updated and old records 4. Process cancellation business rules (memberships, subscriptions, refunds)

Methods Called: - OrderTriggerHandler.afterUpdate(Map<Id, SObject> updatedRecordsMap, Map<Id, SObject> oldRecordsMap) (overridden) - CanceledOrderLogic.run(Map<Id, SObject> updatedRecordsMap, Map<Id, SObject> oldRecordsMap)

Conditional Logic: - Cancellation logic likely checks for specific status transitions - Field-level changes determine processing path

Related Records Updated: - Membership records (status updates) - Subscription records (expiration) - Potentially refund/payment records

Key Business Rules¶

Validation Rules¶

Order updates trigger business logic evaluation
Cancellation logic applies conditional rules based on status

Field Updates¶

Depends on CanceledOrderLogic implementation
Likely impacts order-related memberships and subscriptions

Membership__c records updated
Subscription__c records updated
Downstream financial/inventory impacts

Bulkification & Governor Limits¶

Bulkified: Yes Max Records Handled: 200 Order records per transaction SOQL Queries: Depends on CanceledOrderLogic implementation DML Operations: Depends on CanceledOrderLogic implementation

Bulkification Strategy¶

Trigger passes all updated records to handler as maps
Handler passes full collections to business logic
CanceledOrderLogic handles bulk processing

Governor Limit Considerations¶

SOQL: Queries in CanceledOrderLogic class
DML: DML in CanceledOrderLogic class
Recursion: No explicit recursion prevention visible

Recursion Prevention¶

Strategy: None explicitly implemented in trigger or handler

Implementation: - TriggerHandler framework may have built-in recursion protection - No static variables or flags visible in handler class - CanceledOrderLogic may implement its own controls

Scenarios: - Order update -> CanceledOrderLogic -> updates related records - Related record triggers could update Order (recursion risk) - Monitor for circular updates between Order and related objects

Execution Order & Dependencies¶

Order of Execution Impact¶

After Update: Runs after validation rules and before async processes
Standard Salesforce order of execution applies

Dependent Triggers¶

OrderItemSummaryTrigger: Uses same CanceledOrderLogic class
SubscriptionTrigger: May be impacted by subscription updates
Risk: Shared logic class creates coupling between triggers

Dependent Processes¶

CanceledOrderLogic: Core business logic
Membership management automation
Subscription lifecycle management
Financial/refund processing

Error Handling¶

Strategy: Relies on TriggerHandler framework and CanceledOrderLogic

User Experience: - Success: Order saves, related records updated - Validation Error: Standard Salesforce error messages - System Error: Full transaction rollback, error displayed

Logging: - Logging in CanceledOrderLogic class - No explicit logging in trigger or handler

Rollback Behavior: - Full transaction rollback on errors - All Order and related record changes reverted

Dependencies¶

Apex Classes¶

OrderTriggerHandler: Handler extending TriggerHandler
TriggerHandler: Base framework class
CanceledOrderLogic: Shared cancellation logic

Salesforce Objects¶

Order: Standard object (primary)
Membership__c: Custom object (likely)
Subscription__c: Custom object (likely)
Related financial/inventory objects

Custom Settings/Metadata¶

None currently visible (should add)

External Systems¶

None directly (may be downstream in CanceledOrderLogic)

Testing¶

Test Class: Not specified in trigger comments (check for OrderTriggerHandlerTest) Coverage: Unknown

Test Scenarios: - Single order insert (verify no errors) - Single order update with status change - Bulk order update (200 records) - Order cancellation scenarios - Integration with CanceledOrderLogic - Related record updates (memberships/subscriptions)

Performance Considerations¶

Average Execution Time: Unknown (depends on CanceledOrderLogic) Max Records Processed: 200 per transaction Async Processing: May be used in CanceledOrderLogic

Optimization Opportunities: - Implement field change detection (only process if specific fields change) - Add async processing for non-critical updates - Consider Platform Events for decoupling - Add selective processing based on order type/status

Changes & History¶

2024-06-26: Created by Victor Petica
Author: Victor Petica
Test Class: Not specified
Pattern: Generic trigger handler pattern for all order events

Pre-Go-Live Concerns¶

CRITICAL - Fix Before Go-Live¶

No After Insert Logic: Trigger registers for after insert but handler doesn't override method
Missing Test Class: No test class specified in comments
No Recursion Prevention: No visible recursion control mechanisms
Shared Logic Coupling: CanceledOrderLogic shared with OrderItemSummaryTrigger creates tight coupling

HIGH - Address Soon After Go-Live¶

No Error Handling: No explicit error handling in trigger or handler
No Logging: No logging of trigger execution or business logic routing
Field Change Detection: Processes all updates regardless of field changes
No Trigger Settings: Cannot enable/disable trigger without deployment

MEDIUM - Future Enhancement¶

Add Trigger Settings: Custom metadata to control trigger behavior
Field-Level Tracking: Only process when specific fields change
Async Processing: Consider async for non-critical logic
Better Documentation: Document CanceledOrderLogic integration

LOW - Monitor¶

Performance: Monitor execution time with bulk operations
Governor Limits: Track SOQL/DML usage in CanceledOrderLogic
Integration Points: Monitor shared logic usage patterns

Maintenance Notes¶

Complexity: Low-Medium (simple routing to handler) Recommended Review Schedule: Quarterly

Key Maintainer Notes: - This trigger is very simple - just routes to OrderTriggerHandler - OrderTriggerHandler only implements afterUpdate (not afterInsert despite trigger registration) - All real business logic is in CanceledOrderLogic class - CanceledOrderLogic is SHARED with OrderItemSummaryTrigger - changes impact both - Always test both Order and OrderItemSummary scenarios when modifying CanceledOrderLogic - TriggerHandler framework provides structure but adds dependency - Consider whether after insert is needed or should be removed from trigger

Deactivation Instructions: Add custom metadata check at start of trigger:

trigger OrderTrigger on Order (after insert, after update) {
    if (TriggerSettings__mdt.getInstance('OrderTrigger')?.Disabled__c == true) {
        return;
    }
    new OrderTriggerHandler().execute();
}

Testing Considerations: - Test class needs comprehensive coverage of afterUpdate scenarios - Must test integration with CanceledOrderLogic - Test bulk scenarios (200 orders) - Verify no issues with after insert (even though no logic) - Test order status transitions comprehensively