#Service Cloud68 diskutieren mit

Hey @Ife Ramsey,

Case object are not supported by Duplicate management. For now, this feature only supports accounts, contacts, leads, and custom objects. But, If you really want to use duplicate management directly, you could create a custom object that is linked to the case, replicate the fields you want to check against in that custom object, automate creating/updating that custom object when a case is created, and then use duplicate management against the custom object. This can be completely automated with a flow, no code required. 

Thanks.

Lightning Console?  Like Sales Console or Service Console?    Where does that leave our many associates who only need platform licenses?   We have not been able to fully migrate to Lightning specifically because of this issue - where parity with Classic was not achieved.  Can console applications be created that do not leverage Cases/Opportunities/etc.?   If we need to build a new "Lightning Console App" that can be used by platform licenses then that's something we will consider   But I was of the understanding that by their very nature, lightning console applications leveraged either Sales Console or Service Console.   Please advise.   THanks.

@Tyler Berryhill

good question, and it depends on which threading mode your org uses. Cloning the EmailMessage onto the new case does NOT change the thread token/headers already sitting in the customer's inbox, so under the old Ref ID (ref:_...:ref) threading their next reply still carries the old case's token and lands back on the original case - the clone alone won't re-route it. Header-based / Lightning threading behaves differently: Email-to-Case matches an inbound reply on the Message-ID in the In-Reply-To/References headers and attaches it to the MOST RECENTLY CREATED EmailMessage whose Message-ID matches, so if your cloned EmailMessage preserves the original Message-ID, that clone becomes the newest match and future replies thread onto the NEW case instead of the old one. So Michael's flow works, but only when (a) you're on header-based/Lightning threading and (b) the clone keeps the original Message-ID/headers - on Ref ID threading it won't move the conversation. For the root 'replies reopening closed cases' issue, the cleaner lever is switching to header-based/Lightning threading and using the Email-to-Case reopen settings so a reply to a closed case spins up a new case rather than reopening the old one. If this helps, please mark it as the Best Answer so it helps the next person - thanks!

Yes, this is possible if the Event has a relationship to the Contact that you're creating the Event from.

In Salesforce, validation rules can reference fields on a parent record through a cross-object formula. Salesforce supports cross-object validation rules using relationship fields.  

For example, if your Event is related to a Contact through WhoId

(standard Activity relationship), you may be able to reference the Contact checkbox in a validation rule on Event. 

Example:

 AND(
     ISNEW(),
      Who.Contact_Inactive__c
)

Things to check

1. Does the Event actually have the Contact populated when the validation fires?
   • If users click New Event from the Contact record page, Salesforce typically populates the Contact relationship automatically.
2. Can you see the Contact field in the formula editor?
   • In the validation rule formula editor, click Insert Field and look for the relationship path (often under Who for Contacts/Leads).
3. If the checkbox field is not accessible through a relationship path
   • You may need a before-save Flow, record-triggered Flow, or Apex trigger to prevent creation instead.

Hi Sana, 

Good catch — this looks like a genuine documentation inconsistency, and your test result matches known real-world behavior: the Lightning UI's Add Team Members / Remove All Members buttons are gated by a hardcoded ownership/role-hierarchy check, not by generic "Edit access to the Account" from any source. Sharing-Rule-granted edit access (via Public Group) satisfies the underlying object permission for API/Apex DML, but doesn't unlock the row-level UI actions in Lightning. 

So to directly answer your question: yes, in practice, removing/adding a team member via the standard Lightning UI still requires the user to be the Account Owner, above the Owner in role hierarchy, or have Modify All — Sharing Rule access alone doesn't surface those UI controls, regardless of what the "Public Group" bullet implies. 

What that bullet likely refers to: doing it via the API/Apex directly (not the standard related-list buttons) — a user with Sharing-Rule-based Edit access can successfully insert/delete AccountTeamMember records programmatically, even though they won't see the buttons in the UI. Worth testing that specifically (e.g., via Workbench or an anonymous Apex insert as that user) to confirm — if that succeeds, it confirms the doc is describing API-level access, not the Lightning UI experience. 

If you need this for a couple of specific users without ownership/Modify All, a small custom LWC/Quick Action calling Apex (with sharing) to add/remove members would work, since the underlying permission is already there via your Sharing Rule — you'd just be bypassing the UI's hardcoded ownership check. 

Reference:

Worth submitting feedback on that Help article too, since the wording does read as if the UI buttons should work for Sharing-Rule access. 

Hi Raviraj, 

Try the below path: 

1. Enable WhatsApp as an Enhanced Messaging Channel in Service Cloud, connecting your Meta Business/WhatsApp Business account. 

2. Set up Omni-Channel routing (queue + routing config, or an Omni-Channel flow) so incoming WhatsApp sessions land with the right team, including support for bot-based routing. 

3. Auto-create a Case from an incoming message using an Einstein Bot or Flow — the bot captures the customer's intent, and on unresolved/escalation intents, invokes a flow action to create a Case, tagging it back to the messaging session. 

4. Send updates back on the case (like "latest update") using Messaging Components — reusable structured message templates (Question, List Selector, etc.) that reps or flows can push into the WhatsApp thread, including dynamic content pulled from the Case record. 

5. For proactive/automated updates outside an active session (e.g., status changed to Resolved), use Template-Based Automated Messages — these require Meta-approved templates and the WhatsApp Outbound Messages SKU. 

The exact Trailhead module walking through this entire flow end-to-end (WhatsApp setup → routing → messaging components → case creation) is "WhatsApp for Agentforce Service," which I'd start with since it's hands-on with the Ursa Major Solar org. 

References: 

-

-

-