Flow Name: Account Membership Section Population¶
Last Updated: 2025-09-10 Source Code: Account_Membership_Section_Population.flow-meta.xml
API Name: Account_Membership_Section_Population Status: Active Type: Custom Trigger: Membership record creation/update (after save) when Account_Name__c is not null
Business Purpose¶
Automatically updates Account membership information when membership records are created or modified, maintaining current membership status and historical data based on product type (regular membership or fellow dues).
Process Flow¶
- Triggers when Membership__c record is created or updated with a linked account
- Checks product family: "Membership" or "Fellows Dues"
- For each type, validates if today falls within membership start/end dates OR if this is the current active membership
- For Membership Products: Updates Account with AANP membership details, member type, status, dates, and calculated continuous membership dates
- For Fellow Dues: Updates Account with Fellow membership ID and end date
- Uses complex formulas to calculate member continuity, initial join dates, and membership categories
📊 Click to view Process Flow Diagram
flowchart TD
Start([Start: Membership<br/>Create/Update After Save]) --> HasAccount{Account_Name__c<br/>is not null?}
HasAccount -->|No| End([End])
HasAccount -->|Yes| ProductCheck{Product Family?}
ProductCheck -->|Membership| DateCheck1{Today within<br/>Start/End Dates OR<br/>Current Membership?}
ProductCheck -->|Fellows Dues| DateCheck2{Today within<br/>Start/End Dates OR<br/>Current Membership?}
ProductCheck -->|Other| End
DateCheck1 -->|No| End
DateCheck1 -->|Yes| UpdateMembership[Update Account Membership Fields:<br/>• AANP_Membership__c = Membership ID<br/>• Member_Type__c from Product<br/>• Member_Status__c calculated with grace period<br/>• Membership_Status_Date__c from dates<br/>• Membership_Category__c mapped from type<br/>• Continuous_Member_Since__c calculated<br/>• Initial_Join_Date__c if blank]
DateCheck2 -->|No| End
DateCheck2 -->|Yes| UpdateFellow[Update Account Fellow Fields:<br/>• Fellow_Membership__c = Membership ID<br/>• Fellow_Membership_End_Date__c]
UpdateMembership --> End
UpdateFellow --> End
style Start fill:#e1f5ff
style HasAccount fill:#fff4e1
style ProductCheck fill:#fff4e1
style DateCheck1 fill:#fff4e1
style DateCheck2 fill:#fff4e1
style UpdateMembership fill:#ffe1e1
style UpdateFellow fill:#ffe1e1
style End fill:#e1f5ff
Key Business Rules¶
- Only processes memberships with valid account relationships
- Member status calculated based on end date (30-day grace period) or Corporate Council membership
- Membership category mapping based on Product Member Type (Individual vs Company members)
- Continuous member date logic resets for expired members, preserves for active members
- Initial join date set if blank, otherwise preserved from account
Dependencies¶
- Membership__c custom object with Account_Name__c lookup
- Product2 with Family and Member_Type__c fields
- Account with extensive membership-related fields (AANP_Membership__c, Fellow_Membership__c, etc.)
- Complex formula dependencies on member status calculations
⚠️ Pre-Go-Live Concerns¶
CRITICAL - Fix Before Go-Live¶
- No error handling for account update failures
- Complex formulas could produce unexpected results with edge cases
- Risk of data inconsistency if partial updates fail
HIGH - Address Soon After Go-Live¶
- Very complex business logic combining multiple membership types
- 30-day grace period hardcoded in formula, should be configurable
- Member category mapping hardcoded in formula, difficult to maintain
MEDIUM - Future Enhancement¶
- Split logic for regular and fellow memberships into separate flows
- Externalize business rules (grace period, category mappings) to custom settings
- Add comprehensive logging for membership status changes
LOW - Monitor¶
- Performance with bulk membership updates
- Formula calculation accuracy with edge cases
Maintenance Notes¶
Highly complex flow with extensive business logic embedded in formulas. Critical for membership management. Requires thorough testing when modifying membership processes or adding new member types.