We are currently using the standard Salesforce objects Account and ContactPointAddress to manage Customer Accounts and Delivery Addresses. Every Delivery Address must always be associated with an Account. Recently, after a Salesforce license downgrade, the relationship between ContactPointAddress and Account changed to a polymorphic relationship. As a result, the ParentId field on ContactPointAddress is now polymorphic, which has caused existing Validation Rules and Flows referencing Account fields through this relationship to fail. To address this, we are evaluating the following approaches: Option 1 – Introduce a Dedicated Custom Relationship Create a new custom lookup relationship between ContactPointAddress and Account, populate it using the existing ParentId, and use this custom relationship Option 2 – Handle Everything Through Flows Update all impacted Flows by adding Get Records elements to retrieve the Parent Account data dynamically from the polymorphic ParentId. For Validation Rules, since Salesforce does not support traversing polymorphic relationships in formulas/validation rules, the logic would need to be migrated into Flows entirely. Please suggest us From a long-term architecture and maintainability perspective, which one seems like the cleaner and more scalable approach.
@Murali Pathivada This is a standard polymorphic relationship behavior on ContactPointAddress.ParentId, not something to design around as if it will always stay Account-only. Salesforce’s object reference lists ParentId as a polymorphic relationship that can refer to Account or Individual: https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_contactpointaddress.htm
For long-term maintainability, the cleaner option is Option 1: add a dedicated custom lookup to Account.
Keep ParentId as the standard Salesforce parent relationship, but add something like Account__c on ContactPointAddress and populate it from ParentId when the parent is an Account. Then update validation rules, flows, reports, and formulas to use Account__r instead of trying to traverse the polymorphic Parent.
That gives you a stable relationship path for business logic. Salesforce supports cross-object validation/formula logic through normal lookup or master-detail relationships, which is exactly what the custom Account lookup gives you:
https://help.salesforce.com/s/articleView?id=platform.fields_useful_validation_formulas_cross_object.htm&type=5Option 2 works technically, but it pushes too much logic into flows. Every validation that needs Account data would need a Get Records step, and validation rules that previously referenced Account fields would need to be rebuilt using Flow custom errors. Flow custom errors are useful, but they are heavier to maintain than a clear relationship field:
https://help.salesforce.com/s/articleView?id=platform.flow_ref_elements_custom_error.htm&type=5You should:
Create Account__c lookup on ContactPointAddress
Backfill it from existing records where ParentId points to an Account
Use a before-save flow or Apex trigger to keep it in sync
Add validation to require Account__c if your business says every delivery address must belong to an Account
Move formulas and validation rules to Account__r
Only use polymorphic ParentId where Salesforce requires it
For querying polymorphic relationships, SOQL supports polymorphic handling, but that does not solve the validation rule/formula maintainability problem: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/langCon_apex_SOQL_polymorphic_relationships.htm
