Here’s a comprehensive solution addressing all three issues you’ve raised:
Concurrent Report Editing Solution:
Implement a custom Lightning component that acts as a report checkout system. When someone opens a report for editing, the component creates a temporary lock record (custom object) with the report ID, user, and timestamp. Before allowing edits, check if an active lock exists. Release locks automatically after 30 minutes or when the user saves/cancels. This prevents simultaneous edits without requiring manual coordination.
Alternatively, use Process Builder or Flow to send real-time notifications via Chatter when a report is opened for editing. Create a custom field ‘Currently_Editing__c’ on the Report object that gets populated with the user’s name. While this doesn’t enforce locks, it provides visibility into who’s working on what.
Missing or Incomplete Report History:
The standard solution is Salesforce Shield’s Event Monitoring, but that’s expensive. A practical alternative: create an automation that clones reports before any modification. Use a before-update trigger (requires custom development) or a scheduled job that takes daily snapshots of critical reports into a custom object storing the report JSON definition.
Implement a versioning custom object structure:
- Report_Version__c with fields: Report_ID__c, Version_Number__c, Modified_By__c, Modified_Date__c, Report_JSON__c (Long Text Area)
- Before each save, serialize the current report definition and store it
- Build a simple Lightning component to browse version history and restore previous versions
For the report history gaps, enable the Reports and Dashboards REST API to capture detailed change logs. Create a scheduled Apex job that queries report metadata daily and logs differences to a custom audit object. This gives you the granular tracking Salesforce doesn’t provide natively.
Permission Management for Report Folders:
The viewer-can-edit issue typically comes from folder inheritance problems. Here’s the fix:
- Audit your folder hierarchy - use Sharing Settings to review all folder shares
- Remove Public Group access that grants edit permissions at folder level
- Implement explicit sharing at the report level only, using Permission Sets rather than folder permissions
- Create a dedicated Permission Set ‘Report_Editors’ with ‘Edit My Reports’ and ‘Edit Reports in Public Folders’ permissions
- For viewers, create ‘Report_Viewers’ with only ‘Run Reports’ permission
- Use Apex sharing rules to programmatically control report access based on role or custom criteria
Implementation Priority:
Start with the permission cleanup (immediate impact, no development), then implement the checkout notification system (medium effort, prevents future conflicts), finally tackle the versioning history solution (higher effort but provides long-term audit capability).
For dashboard accuracy specifically, implement validation rules on your source data objects and create a ‘Report Certification’ process where critical dashboards are reviewed monthly and marked with a ‘Certified_Date__c’ field. This ensures accuracy isn’t just about version control but also about data quality governance.
If you need the custom code for the checkout system or versioning trigger, I can provide sample Apex implementations. The key is treating reports as critical metadata that requires the same rigor as your code deployments.
This draft is based on general Salesforce knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.