#Data Management98 人正在讨论

@mathew0406 micheal

Of all the things to do in the world, literally ALL of the the options available (here's just a few)     

• Teach a child to read 
• Help an elderly person
• Donate to a food pantry
• Adopt an animal from a shelter 
• Plant a tree

Instead, you chose to post spam in this Community.  Your parents must be so ashamed of you.

Hi @Rosie Lewis

A few good leads came out of that thread here's the synthesis and what's actually likely going on: 

The LEN vs ISBLANK swap doesn't matter here. For text fields, LEN(field) = 0 and ISBLANK(field) behave identically that's a red herring, not your bug. Also, the AND() logic is correct for what you want (block save only if every field is empty) that's not broken either. 

The real cause is almost certainly one of these two, in order of likelihood: 

1. A Screen Flow or Quick Action is creating the Contact via a path that bypasses validation. If "adding from the organization" (Account) uses a Screen Flow's Create Records element, Flow has a checkbox "Skip the validation rules" (formerly "Skip Salesforce validation rules for this record") that developers sometimes enable to avoid friction. If that's checked, the rule never fires for that path, even though it fires normally when a user saves via the standard Contact edit page. This matches your symptom exactly: same rule, same object, but silently doesn't fire from one specific creation path.
2. A Quick Action ("New Contact" on the Account's Contacts related list) is pre-populating one of the seven fields, most commonly MailingStreet, via a "Predefined Field Value" on the action. If that field gets auto-filled from the Account's Billing Address, the AND() condition is no longer all-blank, so the rule correctly doesn't fire it's not being bypassed, it's legitimately satisfied by data the user didn't type in themselves.

How to confirm which one, without guesswork:

• Setup → Object Manager → Contact → Buttons, Links, and Actions check if "New Contact" on the Account page is a Quick Action, and if so, open it and check "Predefined Field Values."
• Setup → Flows - search for any Screen Flow referencing Contact creation, triggered from the Account page (button, Lightning page component, or Flow action). Open its Create/Update Records element and check the "Skip Validation Rules" checkbox.
• If it's Lightning, also check whether the "New Contact" button on Account is a Lightning App Builder-placed Flow component rather than the standard related-list New button - that changes where to look entirely.

I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too.

Think of AS400 → Staging Layer → Data Cloud.

• MuleSoft/FTP are common, but not mandatory.
• The most sustainable approach is to stage AS400 data in a modern warehouse (Snowflake, Databricks, BigQuery) and then connect that warehouse to Data Cloud.
• This gives you flexibility, scalability, and avoids the limitations of direct legacy integration.

My recommendation: Use an ETL tool (Informatica, Talend, Boomi, Jitterbit) with AS400 JDBC/ODBC drivers to move data into Snowflake or Databricks, then register that source in Data Cloud.

This avoids MuleSoft/FTP and aligns with Salesforce’s supported ingestion patterns. 

Glad to help! If this answers your question, please consider marking it as the

The key condition you’re missing is that Salesforce Data Cloud related lists are only supported for ingested DMOs that have undergone identity resolution and are tied to the Individual DMO. Zero Copy sources can be mapped and unified, but they do not

currently support related lists on CRM page layouts. 

Why Zero Copy Doesn’t Work for Related Lists

• Zero Copy = Federation, not ingestion
  • Data Cloud registers external tables as Data Lake Objects (DLOs) and queries them in place. 
  • The data stays external; only metadata and query paths are stored.
• Related lists require ingested DMOs
  • Related lists on CRM page layouts depend on identity resolution and relationships built on ingested DMOs.
  •  Federated (Zero Copy) DMOs don’t materialize inside Data Cloud, so they cannot be surfaced in related lists.
• Supported downstream features
  • Zero Copy DMOs do work for segmentation, calculated insights, and identity resolution.
  • They don’t support related lists or page layout rendering because those require local object materialization.

Glad to help! If this answers your question, please consider marking it as the Best Answer—it helps others in the community find the solution more easily. Thanks!

In the meantime of https://ideas.salesforce.com/s/idea/a0B8W00000GdlpwUAB/inline-editing-for-related-lists being delivered, in the Winter '27 release, this new feature can solve what you're looking for: 

Process Multiple Records with Screen Flows from List Views and Related Lists -

https://help.salesforce.com/s/articleView?id=release-notes.rn_automate_flow_screen_mass_quick_action_264.htm&release=264&type=5

I just completed a new screen flow for one of our long-term requests here and it came out beautiful!