Skip to content

Flow Name: Person Account Anonymization

Last Updated: 2025-08-20 Source Code: Person_Account_Anonymization.flow-meta.xml

API Name: Person_Account_Anonymization Status: Active Type: Custom Trigger: Platform Event (User_Anonymization__e)

Business Purpose

Handles GDPR-compliant anonymization of Person Account data when users request data deletion, replacing personally identifiable information with anonymized placeholders while maintaining referential integrity. Referenced in PR-29947.

Process Flow

  1. Triggered by User_Anonymization__e platform event containing:
  2. User_Id__c (User being anonymized)

  3. Contact_Id__c (Contact linked to Person Account)

  4. Determine Anonymization Type:

  5. If User_Id__c = "000000000000777": Non-customer account anonymization (skip user lookup)

  6. Otherwise: Customer user anonymization (lookup user first)

  7. For Customer Users:

  8. Retrieves User record by User_Id__c

  9. Gets Person Account by PersonContactId matching Contact_Id__c

  10. Anonymization Logic:

  11. If PersonId__c exists: Uses "GDPR-{PersonId__c}" pattern
  12. Otherwise: Uses username-based patterns
  13. Updates Person Account fields:
    • Name Fields: FirstName, LastName, MiddleName → GDPR-{PersonId} or username
    • AKA Fields: All set to anonymized value
    • Emails: PersonEmail, Email_Secondary__c, Email_Tertiary__c → GDPR-{PersonId}-01/02/03@aanpuat.com
    • Address: City, Street → anonymized, PostalCode → 11111
    • Phone: +10000000000
    • Other: NPI, Region_Territory__c → anonymized
    • Birth Year: Set to (current year - 30)
  14. Sets Anonymized__c = true
📊 Click to view Process Flow Diagram 
flowchart TD
    Start([Start: User_Anonymization__e<br/>Platform Event]) --> CheckType{User ID =<br/>'000000000000777'?}

    CheckType -->|Yes - Non-Customer| GetAccount[Get Person Account:<br/>By PersonContactId]
    CheckType -->|No - Customer User| GetUser[Get User:<br/>By User_Id__c]

    GetUser --> UserFound{User Found?}
    UserFound -->|No| End([End])
    UserFound -->|Yes| GetAccount

    GetAccount --> AccountFound{Account Found?}
    AccountFound -->|No| End
    AccountFound -->|Yes| Formulas[Calculate Formulas:<br/>• NEW_FIRSTNAME/LASTNAME<br/>• NEW_PERSONEMAIL<br/>• NEW_SECONDARYEMAIL<br/>• NEW_TERTIARYEMAIL<br/>• NEW_USERNAME<br/>• NEW_REGION_TERITORY<br/>• birthYear]

    Formulas --> Anonymize[Anonymize Person Account:<br/>• FirstName/LastName/MiddleName<br/>• PersonEmail/Email_Secondary/Tertiary<br/>• AKA Names<br/>• Mailing Address<br/>• Phone = +10000000000<br/>• Profile_Birth_Year/NPI<br/>• Region_Territory<br/>• Anonymized__c = true]

    Anonymize --> End

    style Start fill:#e1f5ff
    style CheckType fill:#fff4e1
    style GetUser fill:#f0e1ff
    style GetAccount fill:#f0e1ff
    style UserFound fill:#fff4e1
    style AccountFound fill:#fff4e1
    style Formulas fill:#e1ffe1
    style Anonymize fill:#ffe1e1
    style End fill:#e1f5ff

Key Business Rules

  • Uses PersonId__c as primary identifier when available
  • Email format: GDPR-{PersonId}-{01/02/03}@aanpuat.com
  • Address anonymized to generic values (PostalCode: 11111, Phone: +10000000000)
  • Birth year calculated as current year minus 30 years
  • Special User ID "000000000000777" indicates non-customer account
  • All formulas handle string length limits (FirstName: 40, LastName: 80, Username: 255)

Dependencies

  • Objects: Account (Person), User
  • Platform Event: User_Anonymization__e
  • Fields Anonymized:
  • FirstName, LastName, MiddleName, PersonEmail
  • AKA_First_Name__c, AKA_Middle_Name__c, AKA_Last_Name__c
  • Email_Secondary__c, Email_Tertiary__c
  • PersonMailingCity, PersonMailingStreet, PersonMailingPostalCode
  • Phone, Profile_NPI__c, Profile_Birth_Year__c
  • Region_Territory__c, Anonymized__c

Changes

PR-29947: This flow is used to update fields on Person Account record in the anonymization process for users whose contactId equals PersonContactId.

⚠️ Pre-Go-Live Concerns

CRITICAL - Fix Before Go-Live

  • Irreversible Action: Anonymization cannot be undone - ensure proper approval workflow exists
  • No Backup: Original data is not archived before anonymization - consider backup strategy
  • Email Domain: Uses @aanpuat.com domain - verify this domain is acceptable for production
  • Missing Validation: Doesn't verify account isn't already anonymized before processing

HIGH - Address Soon After Go-Live

  • Related Records: Doesn't anonymize related Contact, Opportunity, Case records
  • User Record: Doesn't anonymize the User record itself - only the Person Account
  • Audit Trail: No logging of what was anonymized and when
  • Magic Number: Special User ID "000000000000777" is hardcoded and undocumented

MEDIUM - Future Enhancement

  • Comprehensive Anonymization: Create strategy for all related records (Orders, Cases, etc.)
  • Confirmation: Add confirmation step before anonymization
  • Archive Strategy: Store original values in encrypted archive before anonymization
  • GDPR Compliance: Document retention policy for anonymized records

LOW - Monitor

  • Email Uniqueness: Ensure anonymized emails don't conflict with real accounts
  • Birth Year: Verify (current year - 30) is acceptable for compliance
  • Platform Event Delivery: Monitor event delivery failures

Maintenance Notes

Complexity: Medium - Multiple formula fields with complex string manipulation Review Schedule: Annual GDPR compliance review required Critical for Compliance: Core GDPR "Right to be Forgotten" implementation Runs As: TriggeringUser - ensure proper permissions PR-29947: Initial anonymization implementation Legal Review: Changes to anonymization logic may require legal approval