web
You’re offline. This is a read only version of the page.
close
Skip to main content

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Customer experience | Sales, Customer Insights,...
Suggested Answer

View visibility for Activity table.

(0) ShareShare
ReportReport
Posted on by
I have created a new view in activity table. That view should be visible for particular roles and should be hidden for another roles. 
 
I have tried using OOB view settings, it's still visible for all the roles. Is there any limitation in 'Activity' table w.r.t views?
I have the same question (0)
  • Suggested answer
    Inogic Profile Picture
    764 on at
    Hi,
     
    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

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.

Helpful resources

Quick Links

Introducing the 2026 Season 1 community Super Users

Congratulations to our 2026 Super Stars!

Meet the Microsoft Dynamics 365 Contact Center Champions

We are thrilled to have these Champions in our Community!

Congratulations to the April Top 10 Community Leaders

These are the community rock stars!

Leaderboard > Customer experience | Sales, Customer Insights, CRM

#1
ManoVerse Profile Picture

ManoVerse 91 Super User 2026 Season 1

#2
11manish Profile Picture

11manish 72

#3
Muhammad Shahzad Shafique Profile Picture

Muhammad Shahzad Sh... 69 Most Valuable Professional

Last 30 days Overall leaderboard

Product updates

Dynamics 365 release plans