#Salesforce_developer11 personnes en discutent

You’re correct that there isn’t a direct trigger point here. ProcessInstanceWorkitem doesn’t support Apex triggers or record-triggered flows, and reassigning the approval doesn’t update the Case itself. 

If you need to keep the standard Reassign action, I’d handle it with scheduled Apex:

1.  Run a scheduled job every few minutes. 
2.  Query new ProcessInstanceStep records where StepStatus = 'Reassigned'. 
3.  Use ProcessInstance.TargetObjectId to identify the related Case. 
4.  Query the pending ProcessInstanceWorkitem for that process instance to get the newly assigned ActorId. 
5.  Insert a FeedItem with the Case ID as ParentId. 
6.  Store the processed ProcessInstanceStep.Id in a small custom log object with a unique/external-ID field. 
7.  Skip any step already in that log so rerunning the job can’t create duplicate Chatter posts. 

I’d also test it by reassigning the same approval twice and then running the job twice. The expected result should be two Chatter posts total, with no additional posts from the second job run. 

If real-time posting is absolutely required, the other option is to replace the standard Reassign experience with a custom Flow/LWC backed by Apex. That custom action would update ProcessInstanceWorkitem.ActorId and create the Case FeedItem in the same transaction. But the existing standard Reassign action can’t be intercepted directly.

Hi Venkat, 

Good discussion topic. Rather than picking one winner, here's what the data and Salesforce's own market direction actually show: 

Data 360 is the real foundation, not just another skill on the list. 

Salesforce's own Q3 FY26 earnings confirm Agentforce and Data 360 combined are now their fastest-growing revenue line, up 114% YoY to ~$1.4B ARR, with Data 360 ingesting 32 trillion records in a single quarter (up 119% YoY). More tellingly, Salesforce has architecturally folded Data Cloud into Data 360 as the mandatory data layer underneath Agentforce, agents are only as reliable as the data grounding them. This isn't marketing framing, it's a structural dependency: you cannot build a production-grade agent without clean, governed, unified data underneath it. 

Reference:

Agentforce is the visible layer, Data 360 is the plumbing. 

Most professionals will interact with Agentforce (the builder, agent scripting, orchestration), but the differentiated, harder-to-replicate skill will be Data 360 architecture: semantic data modeling, identity resolution, and governance. Agentforce adoption without solid Data 360 underneath is exactly what's producing "agent quietly creates cleanup work" failures being reported across 2026 implementations. 

Apex/LWC isn't going away, but its role is shifting. 

Programmatic skills remain essential for custom actions, complex orchestration logic, and Apex-invoked Agentforce actions, but they're becoming a supporting skill for AI workflows rather than the primary interface, less "build the whole feature in code," more "build the specific action an agent invokes." 

Integration is quietly becoming inseparable from Data 360. 

With Salesforce's Informatica acquisition now folded into Data 360 (bringing data catalog, MDM, and governance natively), integration skill is merging into the Data 360 skillset rather than remaining a separate specialty. If you're building integration expertise, doing it through a Data 360/MuleSoft lens rather than pure point-to-point API work is the more future-proof framing. 

My honest read: if you can only deepen one area over the next 2-3 years, Data 360 (data modeling, governance, identity resolution) has the strongest structural case, it's the layer every other skill (Agentforce, Apex actions, integrations) increasingly depends on to actually work reliably in production, not just in a demo. 

Hi CM Seb, 

Two separate root causes here, both well-documented, and both explain your exact symptom (works as admin in Debug, silently does nothing for guest users on the live site). 

1. Record creation not happening: most likely the flow isn't actually enabled for the Guest User profile, even if it "worked" in Debug. 

Profile-level object permissions (Read/Create on Application) are necessary but not sufficient. You also need to explicitly grant the flow itself to guest users, this is a separate step from object permissions: 

   - Experience Builder > Settings (gear icon) > General tab > confirm "Guest users can see and interact with the site without logging in" is checked, then click the guest user profile link. 

   - Under Enabled Flow Access, click Edit, and confirm your Transitional Coach Application flow is moved into the Enabled Flows column (not just present in the Available list). 

   Reference:

   This is the single most common cause of "works when I test it logged in, does nothing for actual guest visitors", the flow needs this explicit enablement separate from object CRUD permissions. 

2. Emails not sending: this is a hard platform restriction, not a config you're missing. 

As of Spring '23, Salesforce permanently removed the "Send Email" system permission from the Guest User profile across ALL orgs, and since permission sets can't be assigned to guest users either, there is no way to grant this back declaratively. This is intentional (anti-spam/abuse prevention for public-facing guest contexts), not a bug. 

   Workaround: don't send the email directly from the guest-context flow. Instead: 

   - Have the guest flow create the Application record only. 

   - Use a separate Record-Triggered Flow on the Application object (After Save), running as an internal/system context, not the guest user, to send the confirmation email. Since this second flow runs on the object trigger rather than in the guest user's session, it isn't restricted by the Guest User "Send Email" removal. 

Given your record creation is also failing (not just email), I'd fix #1 first, that's likely blocking everything, and once records start getting created successfully, wiring up a Record-Triggered Flow for the email (per #2) will resolve the email gap cleanly without depending on guest user email permissions at all.

Hi Nia, 

Based on the available Salesforce documentation, there isn't a specific release note that states native in-app (Bell) notifications for standard Approval Processes

were introduced in a particular release. The feature has been available in Lightning Experience for several releases, but Salesforce doesn't appear to have a dedicated release note announcing its introduction. 

A few points that may help: 

• Standard Approval Processes can generate native in-app (Bell) notifications for assigned approvers in Lightning Experience.
• No additional setup is typically required to enable the Bell notifications themselves. They are part of the standard approval experience. However, users must have access to the record and the approval process must be configured correctly.
• You can configure email and Chatter notifications for Classic Approval Processes, but Bell notifications aren't exposed as a separate org-level setting to enable or disable.

If you're looking for an official reference, these are the most relevant Salesforce Help articles:

• Approval notification templates and notification behavior: Choose Request Notification Templates for a Classic Approval Process
• Approval notifications in the Salesforce Mobile App: Salesforce Mobile App: How to Submit and Manage Approval Requests

If your goal is to identify when Bell notifications first became available, I haven't found an official Salesforce release note that documents their initial introduction.