#Salesforce_developer19 discussing

 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 @Pavan Kumar Gandi Good question! I believe Agentforce is changing how Salesforce developers work, but Apex and LWC will continue to be important.

AI can reduce repetitive work, while developers can focus more on building intelligent business solutions.

Skills developers should focus on:

1. Apex & LWC – Custom business logic and user interfaces.
2. Flow – Business process automation.
3. Agentforce – Agents, subagents, and custom actions.
4. Agent Script – Control agent behavior and execution logic.
5. APIs & Integration – Connect agents with external systems.
6. Data 360 – Provide relevant business data to AI agents.

Real-Time Example:

A customer asks Agentforce to check an order and update its delivery address. Agentforce can use an Apex action to validate the request, update the record, and return the result.

My View:

Developers should not leave Apex and LWC behind. Strong development skills combined with Agentforce and AI knowledge will create better career opportunities.

Useful Salesforce References:

1. Agentforce Developer Guide: 
   https://developer.salesforce.com/docs/ai/agentforce/guide/get-started-actions.html
2. Custom Apex Agent Actions: 
   https://developer.salesforce.com/docs/ai/agentforce/guide/agent-invocablemethod.html
3. Agentforce with Apex Example: 
   https://developer.salesforce.com/docs/ai/agentforce/guide/apex-examples-custom-action.html

Similar Trailblazer Discussions:

1. Agentforce Learning Path – Admin vs Developer: 
   https://trailhead.salesforce.com/trailblazer-community/feed/0D5KX00000mkCnA0AU
2. Agentforce Access Through Custom LWC: 
   https://trailhead.salesforce.com/trailblazer-community/feed/0D5KX000000mlSg
3. Which Salesforce Skill Will Be Most Important? 
   https://trailhead.salesforce.com/trailblazer-community/feed/0D5KX00000jASm30AG

Keep improving Apex and LWC skills, but start learning Agentforce alongside them. Both are important for future Salesforce projects.

Thanks, @Vishal Soni, @Robbie Duncan, @Kundan Kumar Jha

for sharing your thoughts! 

I agree that Data 360 is becoming an important skill, especially as Agentforce depends on accurate and trusted data.

At the same time, I feel Apex, Flow, LWC, and Integration will continue to play an important role in real-time projects.

Robbie also raised a good point about AI and context engineering. Knowing how to guide and evaluate AI agents will become increasingly valuable. 

My view is that learning one technology is not enough anymore. Understanding how Data 360, Agentforce, and other Salesforce technologies work together will be the real advantage. 

Thanks again for making this a valuable discussion!

Hi @Galla Rajeswari I feel Agent Script is a useful addition to the New Agentforce Builder, especially for complex business requirements.

A few key advantages:

1. Better Control: Define clear business rules and conditions.
2. Consistent Results: Helps agents follow the expected steps.
3. Action Execution: Control when actions should run.
4. Subagent Routing: Manage how agents move between subagents.
5. Less AI Guesswork: Reduces unexpected agent behaviour.
6. Easy Debugging: Makes it easier to understand and fix logic issues.

I believe Agent Script will become an important skill for Salesforce developers, along with Apex, Flow, and LWC.

My View: Canvas is good for visual design, while Agent Script gives developers more control over agent behaviour.

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 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.