#Sales Cloud106 debatiendo

Hi @Lukas Lunow

This gets easier to create an approach, when we look at how each piece works underneath. Not done personally, but this is how i would approach this: 

1. Sending works per row, so create the rows you want sent. MC Next sends one email per record that reaches the send step. If you want one email per account relationship, you need one row per Account Contact Relationship. Build a DMO with a Data Transform, keyed on the ACR Id, with the Contact Id, email and the account fields you need (company name, figures, role) on that row. Two relationships means two rows, which means two emails.
2. Personalization reads from the record being sent, so put the account data on that record. The data graph gets ambiguous when one person has several accounts attached, because nothing tells it which one to pick. If each ACR row already carries its own account data, the merge fields just read from that row and the output is deterministic.
3. Identity resolution is for the person, not the relationship, so let it do only that. Unified Individual exists to collapse the same human into one profile, which is exactly what you want for consent on email. Keep Contact Id as a Party Identification and match on email. Keep account-specific attributes off the Individual, so they never compete in the unified profile. Consent and suppression stay at the person level, and the send grain stays at the relationship level.

The main thing I’d validate is how cleanly MC Next lets you send off a relationship-level DMO while still checking consent on the linked Unified Individual. We can prototype with one contact on two accounts before rolling out. 

Your instinct about the screen flow is right, and it doesn't have to need a developer. 

The core issue is that sharing is all-or-nothing at the record level. Once line B can see a line A Account, it shows up in every report, list view and search. You can't share a record for one screen but hide it in reports. 

So flip the approach: 

1. Remove the sharing rule, so line A Accounts stay private to line A. 

2. Build the screen flow you mentioned, launched from a button on the Opportunity, and set it to run in "System Context Without Sharing". The flow can read the line A record through your lookup and display only the specific fields line B needs. 

3. Show it on the Opportunity page as a screen flow component or quick action, so there are no reports and no broad visibility. 

Watch out: system context also bypasses field-level security. Be deliberate about which fields the flow displays, and document it for your security or audit team (relevant at a firm like yours). 

If line B also needs to report on that information, add a small custom object or a few fields on the Opportunity, filled by a record-triggered flow with a copy of just the fields they need. That gives line B something reportable without opening up the Account.

Yes, this is expected behavior. Salesforce Web-to-Lead creates a Lead record but doesn’t automatically convert it into an Opportunity just because a matching Account exists. You’d need a separate Flow or Apex automation to handle that process. 

For the matching issue, check your active duplicate and matching rules first. Use a tool or software that uses Fuzzy matching logic to help you find out duplicates and accurate lead to account matching.  

Tools like LeadAngel can also help match incoming leads to existing Salesforce Accounts, even when company names have minor variations, so you can handle lead-to-account matching more accurately before deciding how to route or process the lead. 

Hi @Renu Mudhalwadkar

,  

did you ever find out the reason for the described behavior?  

I noticed the same behavior. When we search for a user in "Owner" filter we only see "XXX 's Team" as result coming up, even though this user doesn't have a role below him/her in role hierarchy (and doesn't have a team) and I don't know why. 

I still shows the correct data, but it is irritating for the users/managers. 

Thanks, Sue