#Service Cloud71 debatiendo

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

-

-

-

Hi @Kamlesh Regar

Checking back through our documentation - I can see that we did receive the same error you have detailed. However, we were receiving the error 100% of the time - though you have reported to be inconsistent, so I am not sure if the same issue will resolve. 

We made 2 changes at the same time and resolved the error so I also could not be confident if 1 of these changes would have resolved or it needed both changes. 

We had originally added the salesforce provided script in the head tag instead of the body tag.  The script has now been moved into the body tag. 

We needed to add the site domain into the "Trusted URL" option within setup menu.  After adding the URL, it was essential that we needed to set the "frame-src" checkbox option to "true"   

I am not very confident in this area of front end setup, so I really hope this can help solve your issue!

Yes here is how you do it:

1). Use DataLoader and export all of the 'ContentDocument'

2). In the CSV file that gets extracted, look for the 'LATESTPUBLISHEDVERSIONID' Column

3). Add another column to the Excel file on the right of 'LATESTPUBLISHEDVERSIONID' and use the formula =CONCATENATE("URL",R2)

Basically what we are trying to do is fill this next column with urls like : 

https://YOUR_INSTANCE_URL/sfc/servlet.shepherd/version/download/LATESTPUBLISHEDVERSIONID

So at the end of it all you should have rows and rows that look like this:

https://YOUR_INSTANCE_URL/sfc/servlet.shepherd/version/download/SOMEVERSION

https://YOUR_INSTANCE_URL/sfc/servlet.shepherd/version/download/SOMEVERSION

https://YOUR_INSTANCE_URL/sfc/servlet.shepherd/version/download/SOMEVERSION

https://YOUR_INSTANCE_URL/sfc/servlet.shepherd/version/download/SOMEVERSION

https://YOUR_INSTANCE_URL/sfc/servlet.shepherd/version/download/SOMEVERSION

Now all you have to do is get a chrome extension called 'TAB SAFE' which is listed here: 

Tab Save (google.com)

And whatever block of urls you put there, it will down load all of the files. 

If you dont like dealing with excel and are more excel savvy, you can write custom Apex to export the URL's. As long as you can copy paste those URL's in that Chrome extension, it should be able to download all those files.

Let me know if this works for you.  

Short answer: no - native Case Escalation Rules only let you pick 0 or 30 minutes for 'Age Over' (you enter the hours, then choose 0 or 30 from the dropdown). Custom values like 12 or 20 minutes are not possible there; it is a fixed platform limit. 

For minute-precise escalation, use one of these instead: 

1. Record-Triggered Flow with a Scheduled Path (easiest): add a scheduled path set to run, say, 12 or 20 minutes after your date/time field (or after the case is created / meets criteria), and put the escalation action - reassign to a queue, send an email, update a field - in that path. Scheduled paths accept any custom minute value. 

2. Entitlements + Milestones (the full SLA framework): 'Minutes to Complete Milestone' accepts any number, and Milestone Actions fire at exactly that time - ideal if you are tracking support SLAs. 

Go with the Flow scheduled path if you just need custom timing; use Milestones if you want a proper SLA model on Cases. 

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