Skip to content

Flow Name: User after save (async)

Last Updated: 2024-11-14 Source Code: User_after_save_async.flow-meta.xml

API Name: User_after_save_async Status: Active Type: Custom Trigger: After Save - User Record Update (with AsyncAfterCommit path)

Business Purpose

This flow maintains data synchronization between User records and their associated Person Accounts for internal AANP staff users. When specific User fields are updated, this flow automatically updates the corresponding fields on the related Person Account to ensure data consistency across both objects.

Process Flow

  1. Trigger: Flow executes after User record is updated (not on create)
  2. Field Change Detection: Only triggers when specific fields change:
  3. CompanyName, FirstName, LastName, Email, Phone
  4. Address fields: Street, City, State, PostalCode, Country
  5. Async Processing: Uses AsyncAfterCommit to avoid transaction limits
  6. Account Lookup: Searches for Account where InternalUser__c = User.Id
  7. Account Verification: Checks if related Person Account exists
  8. Data Synchronization: Updates Person Account fields with User data
  9. Phone Type Assignment: Hardcodes Phone_Type__c = "Work"
📊 Click to view Process Flow Diagram 
flowchart TD
    Start([Start: After Save - User Record Update (with AsyncAfterCommit path)]) --> Screen[Display Screen:<br/>User Input Required]

    Screen --> UserInput[User Enters Data]
    UserInput --> Process[Process Input]
    Process --> Action[Execute Action]
    Action --> End([End])

    style Start fill:#e1f5ff
    style Screen fill:#fff4e1
    style UserInput fill:#e1ffe1
    style Process fill:#ffe1e1
    style Action fill:#ffe1e1
    style End fill:#e1f5ff

Key Business Rules

  • Only processes User record updates (not creates)
  • Only triggers when monitored fields change (OR condition)
  • Only affects Person Accounts linked to internal users via InternalUser__c field
  • Automatically sets Phone_Type__c = "Work" on updated accounts
  • Uses async processing to avoid governor limits

Dependencies

  • User object with address and contact fields
  • Account object with InternalUser__c custom field
  • Person Account functionality enabled
  • Field mapping between User and Account PersonMailing fields

Changes

[PR-29737] Higher Logic update person account of internal user

⚠️ Pre-Go-Live Concerns

CRITICAL - Fix Before Go-Live

  • Missing Error Handling: No fault paths for Account lookup failure or update failure
  • Data Loss Risk: No validation that User fields contain valid data before copying to Account
  • Single Account Assumption: Uses getFirstRecordOnly but doesn't handle multiple matches

HIGH - Address Soon After Go-Live

  • Null Value Handling: No null checks before updating Account fields - could overwrite valid data with nulls
  • Bulk Update Impact: AsyncAfterCommit could cause performance issues during bulk User updates
  • Data Validation: No validation of address format or email validity before updating Account

MEDIUM - Future Enhancement

  • Audit Trail: No logging of which User changes trigger Account updates
  • Field Validation: Consider adding validation for required fields before updating Account
  • Bidirectional Sync: No mechanism to sync changes from Account back to User
  • Phone Type Logic: Hardcoded "Work" phone type could be made dynamic

LOW - Monitor

  • InternalUser__c Relationship: Monitor integrity of InternalUser__c field relationships
  • Address Format: Monitor for address formatting issues across User/Account fields
  • Update Frequency: Monitor how often this flow executes during normal operations

Maintenance Notes

This is a LOW-MEDIUM COMPLEXITY flow that maintains critical data synchronization between User and Person Account records for internal staff. It ensures that: - Staff contact information stays synchronized - Person Account data reflects current User information - Address and contact details remain consistent

Data Integrity Considerations: - Synchronizes 10 different field mappings - Potential for data inconsistency if flow fails - Risk of overwriting valid Account data with invalid User data

Performance Considerations: - Uses AsyncAfterCommit to avoid transaction limits - Single SOQL query per execution - Could impact bulk User data maintenance operations

Recommended Review Schedule: - Before User object field changes - Quarterly review of InternalUser__c field relationships - Before bulk User data updates or migrations - When Person Account structure changes

Critical Dependencies: InternalUser__c field relationship integrity, Person Account structure stability