#Data Management100 diskutieren mit

@Reno Redaja

Document Processing runs as an Agentforce agent action, so it isn't on a separate meter - it draws from your Agentforce Flex Credits (the same metered pool your agent actions use, billed monthly in arrears). Data Cloud has its own Flex Credits for Data Cloud operations, but the agent-action invocation itself is Agentforce credits. 

To see it, go to Setup > Digital Wallet - that's the central, near-real-time dashboard for Flex Credit consumption (agent actions, usage, balances). You won't find a line literally labelled 'Document Processing'; it shows up as the consuming agent's action usage, so read it there by agent/action. You can also add Consumption Threshold Alerts via a Flow to get notified as usage climbs. 

If this helps, please mark it as the Best Answer so it helps the next person - thanks!

Hey Misty, 

Your read is accurate: per Salesforce's own docs, Related Record Matching is an org-wide, all-or-nothing setting, when it's on, ECI runs its own algorithm (participant email/domain matching against Contact, Lead, Account) and populates the Related Record field automatically. If you want to run your own Flow-based matching logic instead (your name-against-Contact/Lead + subject line idea), you have to turn Related Record Matching OFF entirely, then a Flow becomes the only thing setting that field. You can't layer a supplemental Flow on top of the native matching to "catch the extra 10-20%", it's one or the other, not additive. 

Given that, your options really are: 

1. Turn off native matching, build your own Flow to replicate ECI's built-in logic PLUS your extra fallback rules (name-against-Contact/Lead, subject line parsing). This means you inherit responsibility for the baseline matching ECI already does well, not just the edge cases, that's a bigger lift than it initially sounds. 

2. Keep native matching on, and instead build a separate Flow/batch job that runs afterward on unmatched records only, checking if Related Record is null, then applying your own supplemental logic to update it. This avoids fighting the native system since you're only touching records ECI already gave up on, not replacing its matching entirely. 

3. Turn on Einstein Activity Capture integration alongside ECI, per Salesforce's own guidance, this specifically enhances guest participant matching quality, which sounds directly relevant to your "joining from a car/conference room" problem, worth testing before building custom logic at all. 

On

or similar tools: since ECI's matching is a Salesforce-side process, not tied to which video/transcription vendor recorded the call, a third-party transcription add-on wouldn't conflict with ECI's matching logic, but it also wouldn't replace or feed into it automatically. It solves a different problem (better transcript quality) than record-matching itself. 

Given the scale you're describing, option 2 (supplement only nulls, don't disable native matching) is usually the least disruptive path, worth prototyping that before considering a full matching rebuild. 

Reference:

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.

@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.

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!