#Data Management101 人がディスカッション中

@Sabeer Shahzad

Both your options fight Salesforce's record locking — #1 hits it head-on (only one person can edit a record at a time, so the others get locked out or hit a 'record was modified' conflict), and #2 gets messy fast. The cleaner move is to not have them share one record's fields at all. 

Model each analyst's work as its own child record — a related 'Analysis' object, one per analyst per Financial record. Everyone edits their own child, so there's zero lock contention, and you surface them all together on the parent (a related list, or a small LWC that lays the analyses side by side). Your Reviewer then sees everyone's work in one place and nobody blocks anyone. 

If you truly need 'see each other's answers live as they type', Salesforce isn't real-time-collaborative like a Google Doc out of the box — you'd layer an LWC that refreshes (or push updates via Platform Events / Change Data Capture). But the child-record model gets you most of the way on save, without the locking headache. 

If this helps, please mark it as the Best Answer so it helps the next person — thanks 🙂

Hi @Reno Redaja

Based on Salesforce’s current Flex Credits model, Document Processing should be evaluated as part of the metered Agentforce usage rather than assuming it has a completely separate credit pool. Salesforce uses Flex Credits for metered Agentforce actions, and usage can be monitored through Setup → Digital Wallet. 

If you don’t see a specific “Document Processing” entry, check the relevant usage type/action details in Digital Wallet, since Salesforce groups consumption by usage type rather than necessarily displaying every feature as a separate line item. 

I’d also recommend checking your org’s Flex Credits Rate Card/contract, because the actual multiplier and billing treatment can depend on the specific usage type and entitlement.  

Hope this helps clarify where to look. 

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!