IdeaExchange

Since Salesforce recommended to update our integration users from "System Admin" users to the Salesforce Integration user, I have been trying unsuccessfully to get our integration user to trigger Auto-Response emails via Auto-Response Rules when cases are created from Form-to-Case. While this result can be achieved via flow, I did not want to have to manage Case Auto-Response Rules in 2 places ( Flow and Auto-response Rules) 

Salesforce Support's final email said that this may be an oversight in the current design of the Salesforce Integration User license and a current product limitation.    

I would love to see the permission to trigger the Case Auto-Response rule extend to the Salesforce Integration license so we can use out of the box functionality and not have to build custom processes. Unfortunately I will have to keep using a regular Salesforce License user as my integration user until that is resolved. 

If anyone has found a better workaround, I would love to know!

Am I the only one to think this new thing is not ready?  

I had a bad experience. First, I had no other choice then use my personnal phone to make it worked. Then, it worked for sometime and block. It was not my phone As I was able to log on other sandbox with the exact same set up with a keypass using my Phone. I had to open a ticket and wait few days before they can unblock me. Fortunately, it was for one of my Sandboxs. But I Can't imagine having the same issue in Production. I fully understand the need, but... it has to work. 

Our GSOC (Global Security Operations Center) is now monitoring Salesforce logs. 

For some logs the volume is huge, so we add filters in our SIEM's collect server to filter on the "PolicyID" of Event Monitoring / Transaction Security Policies. 

However for the "API Event" big object the PolicyID is always empty leaving us no possibility to filter on that. 

Anyone has already encountered the same issue? how did you proceed? would there be a way to filter this directly from the Salesforce API?  

Thank you very much beforehand.

We have several reports that users reuse all the time, making edits to the filters to fit their needs. We don't want them saving their edits to the report, but they're finding that after re-authenticating, the report runs with the original filters rather than the edited one. Is there a way around this?

Is there a way in Salesforce Sales Engagement cadences to require reps to update or personalize an email before it can be sent?  

We are looking to prevent users from sending cadence emails without first making an update to the email body or subject line. Ideally, we'd like the email step to require some level of personalization before the email can be sent.

Is there a native setting, validation, customization, or best practice that would:

• Require edits to the email template before sending
• Prevent sending if no changes have been made
• Prompt users to personalize the email
• Track whether an email was customized prior to sending

If this is not available out of the box, are there any recommended workarounds or custom solutions?

 The current Apex Crypto Class in Salesforce only supports AES encryption in CBC mode, which is susceptible to padding oracle attacks. To enhance security, it is important for the Apex Crypto Class to also support more robust encryption algorithms, such as AES in GCM and CCM modes, which have been available for some time. Implementing these advanced encryption modes would significantly improve data protection and align with modern security standards. 

The 120 minute limit for exporting reports before you need to authenticate is becoming cumbersome. Is this something that we have the option to change? I am requesting a feature change to be able to configure the time limit per org.  

It would be great if administrators could configure a default Organization-Wide Email Address for Incident Broadcast Emails. 

This would help organizations provide a consistent sender experience during customer communications, while ensuring replies are directed to the appropriate support team. An option to make the default sender mandatory, or to limit the available sender addresses for Broadcast Emails, would provide additional flexibility for organizations with multiple brands or teams. 

This enhancement would simplify administration and reduce the need for custom solutions just to standardize the sender address.

We just updated the method for calculating some fields on some of our standard Sales Cloud objects.  These have different API names but, importantly for UX, the same label as before. 

When these are ingested into the DLO in Data Cloud, the old fields can be disabled in the DLO using their API name, but in the mapping tool on both visual and table views only the label is visible, so it's impossible to know which field you are mapping.  There's also no option to edit the label. 

My suggestion is that the API name be visible in the table view of the Mapping Tool, or that disabled fields do not appear in the Mapping Tool, or both. 

Does anyone have another solution?  I've already been through SF support which didn't find one but I'm wondering if there is one you've come across.