IdeaExchange

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.

Salesforce users: If you could fix ONE thing in Salesforce tomorrow, what would it be?

Reporting? Automation? Data management? Integrations? Something else?

Drop your biggest Salesforce pain point below. Curious to see what the community is struggling with most.

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. 

A platform-native data dictionary

that integrates with Salesforce’s metadata and permissions system as an out-of-the-box feature, rather than a third-party or AI tool which could be more vulnerable to attack.  This would provide: 

• Automated documentation of all custom/standard objects, fields, and relationships in a centralized, searchable view.
• Permissions context showing why users/groups have access to specific fields/objects (e.g., profiles, permission sets, sharing rules, manual overrides).
• Data governance integration linking fields/objects to compliance rules, retention policies, and AI usage constraints.
• Permissions repository tracking changes over time and flagging orphaned/unused fields.
• Impact analysis to visualize dependencies (e.g., flows, reports, or processes using a field).
• Audit-ready reporting for compliance (e.g., GDPR, HIPAA).

This would reduce manual effort, minimize risk, and improve transparency for admins, data stewards, and auditors.

Allowing users to tag records and find shared tags could replace rigid picklists with a flexible way to categorise Cases. Reporting on these tags across objects would make the data far more useful, especially as Salesforce pushes for AI-ready data. Built on Chatter, this feature may never evolve further—but it’s exactly the kind of lightweight, adaptable system Salesforce should revisit.

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!

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.