Flow Name: Order BeforeSave Status Validation¶
Last Updated: 2025-09-17 Source Code: Order_BeforeSave_Status_Validation.flow-meta.xml
API Name: Order_BeforeSave_Status_Validation Status: Active Type: Custom Trigger: Order record before save when Status field changes to "Activated" or "Ready for Activation"
Business Purpose¶
This flow enforces business validation rules when order status changes, ensuring orders meet specific requirements before advancing to "Ready for Activation" or "Activated" status. It validates that orders have associated products, PAC contributions stay within daily limits, and payment transactions are complete before activation.
Process Flow¶
- Status Change Detection: Triggers when Order Status field changes to "Activated" or "Ready for Activation"
- Status Validation Logic:
- Draft → Ready for Activation: Validates order products exist and PAC contribution limits
- Pending Payment → Activated: Validates approved transaction exists with zero balance
- Order Products Check: For "Ready for Activation" status, ensures at least one OrderItem exists
- PAC Contribution Validation: Checks if Order.PACTotal__c exceeds daily limit of $100
- Transaction Validation: For "Activated" status, verifies approved Chargent transaction exists with zero balance due
- Error Handling: Displays appropriate custom error messages to prevent invalid status changes
📊 Click to view Process Flow Diagram
flowchart TD
Start([Start: Order record before save when Status field changes to "Activated" or "Ready for Activation"]) --> Check{Entry Criteria<br/>Met?}
Check -->|No| End([End])
Check -->|Yes| Process[Execute Business Logic]
Process --> Update[Update Records]
Update --> End
style Start fill:#e1f5ff
style Check fill:#fff4e1
style Process fill:#e1ffe1
style Update fill:#ffe1e1
style End fill:#e1f5ff
Key Business Rules¶
- Orders cannot be marked "Ready for Activation" without at least one order product
- PAC contribution orders cannot exceed $100 daily limit (PACTotal__c field)
- Orders cannot be "Activated" from "Pending Payment" without:
- An approved Chargent transaction (Response_Status__c = "Approved")
- Zero balance due on the related Chargent order (Balance_Due__c = 0.0)
- Flow only processes status changes, not new order creation
- Uses before-save trigger to prevent invalid record saves
Dependencies¶
- Order object with Status, PACTotal__c fields
- OrderItem object linked to Order
- ChargentOrders__Transaction__c object with Order__c lookup and Response_Status__c field
- ChargentOrders__ChargentOrder__c object with Balance_Due__c field
- Relationship between Transaction and ChargentOrder objects
Changes¶
[No specific PR or change notes documented in the flow]
⚠️ Pre-Go-Live Concerns¶
CRITICAL - Fix Before Go-Live¶
- Hardcoded PAC daily limit of $100 should be configurable via custom metadata or settings
- No error handling if ChargentOrder lookup through Transaction fails
- Transaction lookup uses "Order__c" field that may reference Standard Order, not ChargentOrder
HIGH - Address Soon After Go-Live¶
- PAC limit validation only occurs on "Ready for Activation" - users could bypass by going directly to other statuses
- Single transaction lookup may miss cases where multiple transactions exist for an order
- No validation of payment method or payment completion beyond balance due check
MEDIUM - Future Enhancement¶
- Could validate specific order product types or minimum amounts
- No audit trail of validation failures or bypass attempts
- Consider different validation rules based on order type or product family
- Error messages could be more specific about what user needs to do
LOW - Monitor¶
- Element name "Get_Realted_Transaction_Line" has typo - should be "Related"
- Flow could benefit from additional context in error messages
- Consider consolidating validation logic with other order validation flows
Maintenance Notes¶
This flow implements critical business validation rules that prevent data integrity issues. The PAC contribution limit and payment validation logic should be reviewed regularly to ensure compliance with regulatory requirements. When updating validation rules, ensure all possible order status transition paths are tested. Monitor for any changes to Chargent object structure that might affect transaction validation logic.