After updating object security settings on our audit records last Friday, our main compliance dashboard is showing incomplete data. About 40% of audit records are missing from the dashboard views, even though I can see them when I navigate directly to the audit management module.
The security change was intended to restrict edit access to certain audit types, but we only modified the ‘Edit’ permission level. View permissions should have remained unchanged for all users with the ‘Audit Viewer’ role.
Here’s what I’m seeing in the security matrix:
Audit Record Object:
- Role: Audit Viewer
- View: Enabled (All Records)
- Edit: Disabled
- Dashboard Access: Enabled
The dashboard filters are set to show all audits from the last 90 days with status ‘Completed’ or ‘In Progress’. Users are reporting they can’t see audits they were previously tracking. This is impacting our compliance reporting cycle. Anyone dealt with dashboard filter dependencies breaking after security changes?
You’ve identified part of the issue, but let me explain the complete picture of what’s happening with your dashboard and how to fix it properly.
Object Security Settings:
Your security matrix shows ‘View: Enabled (All Records)’ for Audit Viewer role, but Veeva Vault has a critical distinction between object-level view and query-level view. When you modified the Edit permissions, you likely also triggered a recalculation of the security model that affected how dashboard queries execute. Dashboard queries use a stricter security context than direct navigation.
The key issue: Dashboard queries require both object-level view AND query permission on the role. Check Admin > Security > Role Definitions > Audit Viewer > Query Permissions. This is often overlooked.
Dashboard Filter Dependencies:
Your dashboard filters reference ‘audit_owner__c’ and implicitly reference ‘audit_finding_details__c’ in the column display. Here’s what’s breaking:
Dashboard Security Chain:
1. Query Permission (role-level) → Must be enabled
2. Object View Permission → You have this
3. Field View Permission (for ALL fields in query) → Missing for audit_finding_details__c
4. Filter Field Security → audit_owner__c needs verification
When ANY field in this chain fails security, Veeva excludes the entire record from dashboard results without logging an error. This is by design for security reasons.
Role-Based Access Control Fix:
Here’s the systematic approach:
-
Enable Query Permission:
Admin > Security > Role Definitions > Audit Viewer
Add ‘Audit Record Object’ to Query Permissions list
-
Verify Field-Level Security:
Admin > Objects > Audit Record Object > Fields
For each field used in dashboard (filters + columns):
- audit_owner__c: Add Audit Viewer to field security (View)
- audit_finding_details__c: Add Audit Viewer to field security (View)
- status__v: Verify Audit Viewer has View access
- created_date__v: Verify Audit Viewer has View access
-
Update Security Matrix:
After adding field permissions, refresh the security matrix:
Admin > Security > Refresh Security Cache
-
Test Dashboard Query:
Create a test report with the same filters as your dashboard. If the report shows all records, the dashboard will too. If not, there’s still a field-level restriction.
Why Records Disappear Completely:
Veeva’s security model uses ‘fail-closed’ logic for dashboards. If a query includes a field the user can’t see, rather than showing the record with that field blank, it excludes the entire record. This prevents security leaks where users could infer restricted data from partial records.
Implement these changes and your 40% missing records should reappear. The security change last Friday likely enabled stricter query-level security enforcement that wasn’t active before.
Security changes can definitely affect dashboard visibility in unexpected ways. Check if your dashboard filters include any fields that now have field-level security restrictions. Even if object-level view is enabled, if a filter references a restricted field, the entire record might be excluded from results.
That’s a good point about field-level security. I checked and we do have a filter on ‘audit_owner__c’ which might have field security. How do I verify if that field has restrictions? Is there a way to see which fields are causing records to be filtered out?