In Dynamics 365, the Activity table behaves differently compared to standard tables when it comes to view visibility and security-role-based access. The OOB "Display to specific security roles" setting on System Views does not always work reliably for the Activity table because Activities are implemented using the shared ActivityPointer architecture (Email, Task, Phone Call, Appointment, etc. all inherit from it). Because of this architecture, even if a view is restricted to selected security roles, users who have access to Activities may still be able to see the view. This is a known platform limitation associated with Activity-based tables and unified activity experiences.
Below are a few things you can verify before concluding it is platform behaviour: 1. Verify the View Type Ensure the view is a System View and not a Personal View. Role-based visibility settings apply only to System Views.
Go to: Tables → Activity → Views
Open the view properties and confirm it is created as a System View.
2. Publish Customizations After modifying view visibility settings:
Click Publish All Customizations.
Clear browser cache or open the application in an Incognito/InPrivate session. Sometimes old metadata is cached and the previous visibility still appears.
3. Check How the View Is Being Accessed In Activity tables, views can appear through multiple UI components which may not fully dedicated to the "Display to specific roles" configuration. a. Timeline Control If Activities are shown inside the Timeline on forms such as Account, Contact, Lead, or Opportunity, Dynamics internally uses Activity queries rather than standard view rendering. Because of this, users may still see Activity views indirectly through Timeline, and the Timeline control can bypass standard view visibility behavior. How to verify:
Open a record form (e.g., Account).
Check the Timeline section.
See whether the custom Activity view is appearing there.
b. Associated Activities View When users navigate through Related → Activities, Dynamics uses special associated Activity views linked to ActivityPointer. These associated views do not always respect role-based view filtering and may expose the custom view even when restricted. How to verify:
Open any parent record.
Navigate to Related → Activities.
Check whether the custom view is available there.
c. App Module Navigation If the Activity table or the specific view is included inside a Model-Driven App sitemap/navigation, users may still access it through the app. Even if the view is role-restricted, app navigation can still surface the view, especially when the app itself is assigned to broader roles. How to verify:
Open App Designer.
Check whether the Activity entity/view is included in the sitemap.
Validate which security roles are assigned to that app.
Recommended Solutions: - 1. App-Level View Control Instead of relying only on view-level security, create separate Model-Driven Apps for different roles, include only relevant Activity views in each app, and assign apps to specific security roles. This approach is more reliable for Activity entities.
Create separate Model-Driven Apps for different roles.
Include only relevant Activity views in each app.
Assign apps to specific security roles.
2. JavaScript-Based View Handling For subgrids or form-based scenarios, you can use JavaScript to dynamically change or hide views based on the logged-in user's role. This is a client-side approach and works well when strict UI control is required.
3. Custom Activity Tables If strict segregation of views is required, consider creating separate custom activity tables instead of relying on the shared ActivityPointer architecture. based on known platform behaviour there are practical limitations with OOB role-based view visibility on the Activity table in Dynamics 365 due to the underlying ActivityPointer implementation. The App-Level View Control approach using the Model-Driven App Designer is the most maintainable and supported solution.
Hope this helps.
Thanks!
Inogic
Was this reply helpful?YesNo
Under review
Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.