#Sales Cloud103 人正在讨论

Thanks Guys,      Owner.Email isn't working as  OppUser_Name  is not the record owner,  all  names in the OppUser_Name field are the salesforce users, and their email address is in the user details,  Just think if I can create a new field  OppUser__Email ookup the OppUser_Name field in opportunity, and find the name field in the user then extract the user's email address  from salesforce user details to opportunity field OppUser__Email 

 Hi @Akhilesh Prajapati

To improve Email-to-Case reliability and minimize the impact of routing failures, I would recommend the following approach:

1. Maintain an email backup: Configure your email server to retain a copy of every incoming support email in the original mailbox or a dedicated backup folder before forwarding it to Salesforce.
2. Configure a secondary routing option: Maintain a separate backup support mailbox or alternate intake channel. If the primary forwarding configuration fails, your email administrator can redirect incoming emails to the backup route. Test this setup carefully to avoid duplicate cases.
3. Monitor processing failures: Configure the Automated Case User's email address to deliver Salesforce Email-to-Case error notifications to a monitored internal mailbox or distribution group.
4. Enable error notifications: In Setup, navigate to Feature Settings → Service → Email-to-Case and review the option to notify senders about processing errors.
5. Test the Salesforce routing address directly: Send a test email to the generated Email Services Address. If a case is created, investigate the external email forwarding configuration. If no case is created, check the Automated Case User's permissions, record types, validation rules, Apex triggers, and Flow automation.
6. Implement monitoring: Use email-platform monitoring to alert administrators when forwarding rules change or message delivery fails. You can also periodically send test emails and verify that corresponding cases are created.
7. Establish a recovery procedure: During an outage, preserve affected emails and create or resubmit cases after the issue is resolved. Before replaying messages, check whether a case already exists to avoid duplicates.

Salesforce documentation:

• Troubleshooting Email-to-Case: https://help.salesforce.com/s/articleView?id=000384980&language=en_US&type=1
• Email Retention and Error Prevention: https://help.salesforce.com/s/articleView?id=000387063&language=en_US&type=1
• Email-to-Case Forwarding Guidelines: https://help.salesforce.com/s/articleView?id=service.customizesupport_forwarding_guidelines.htm&language=en_US

For a production environment, I would prioritize retaining inbound emails, monitoring processing errors, and documenting a tested recovery procedure before implementing a more complex failover solution.

I hope this helps! If you find this answer helpful, please select it as the Best Answer. 

Thanks, 

Deepak Sachdeva 

Nubys Technology Pvt. Ltd.

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.

Hello @Abby M, if you do not plan to request LinkedIn, and just navigate to it, you may create a custom field that will host the linkedin identifier of the contact, with a hyperlink formula to create the link to the linkedin page, on your contact detail page.  

Example : https://trailhead.salesforce.com/trailblazer-community/feed/0D54S00000A9C2QSAV

Eric

Hi @Lorrany Souza, 

Ensure the users have the required Sales Engagement permissions (typically through the Sales Engagement User permission set) and access to the cadence tracking records. Active cadence targets can be removed using the standard Remove from Cadence action, even after steps have started, provided the user has the necessary permissions and record access. 

Remove Prospects from a Sales Engagement Cadence | Salesforce Help

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