Microsoft Dynamics 365 Customer Experience Analyst : Evaluate security privileges by using access checker
The Access Checker in Dynamics 365 and the Power Platform is a useful tool that helps administrators and makers quickly verify a user’s security privileges for a specific record. Instead of manually analyzing security roles, hierarchy settings, and team memberships, the Access Checker provides a clear view of whether a user can Read, Write, Append, Share, Assign, or Delete a particular record, and explains why access is granted or denied. This is especially helpful when troubleshooting permission issues in complex security models involving business units, field-level security, and record ownership. By using the Access Checker, organizations can save time, improve security management, and ensure users have the right level of access to perform their jobs effectively.
- Whether a user has access to a record.
- What type of access (Read, Write, Append, Assign, Delete, Share).
- Why access is granted or denied (e.g., role-based, team, sharing, or hierarchy).
- Go to the record you want to evaluate in Dynamics 365.
- On the command bar, select Check Access (sometimes found under the “...” menu).
- In the Access Checker pane, search for and select the user whose access you want to evaluate.
- Read → Can the user view the record?
- Write → Can they edit/update the record?
- Append / Append To → Can they link related records?
- Assign → Can they reassign the record?
- Share → Can they share the record with others?
- Delete → Can they remove the record?
- Security Role privilege (e.g., Salesperson, Custom Role).
- Team membership (if the user inherits permissions through a team).
- Shared record (record explicitly shared with the user).
- Hierarchy Security (manager-level access).
- Troubleshooting – Quickly resolve user complaints like “I can’t update this record” by checking their actual privileges.
- Transparency – Helps admins explain why access was given or denied.
- Security Validation – Confirms that sensitive data is only visible to the correct roles or teams.
- Faster Admin Work – Avoids manually analyzing multiple security roles and configurations.
- Use Access Checker regularly when designing or testing new security roles.
- Always evaluate record-level access, not just role assignment, since sharing and teams can override role privileges.
- Document the results when troubleshooting user issues for future reference.
- Combine Access Checker insights with audit logs to get a full picture of user access and activity.
- Design Validation → Ensures that the security model (business units, teams, roles, hierarchy security, and record sharing) is correctly implemented.
- Principle of Least Privilege → Helps architects confirm that users have just enough access (no more, no less) to perform their job.
- Troubleshooting Tool → Simplifies diagnosing complex permission issues across cross-functional teams and environments.
- Audit & Compliance → Demonstrates why a user has (or does not have) access — useful for regulated industries.
- Scalability → Guides decisions when extending apps to new regions, departments, or large user groups by testing access scenarios before rollout.
For architects, the Access Checker = a control point for aligning technical security design with business requirements and compliance needs.
- Plugin/Workflow Debugging → Ensures that users running automation (plugins, Power Automate flows) have the right privileges for target records.
- Error Diagnosis → Helps identify root causes of security-related errors like “Insufficient privileges” exceptions in custom code.
- Record-level Security Testing → Confirms that custom logic respects security roles, teams, and sharing.
- Custom Solutions Alignment → Ensures code aligns with the security model instead of bypassing it.
- Developer Efficiency → Reduces time spent manually analyzing multiple security roles and privilege tables in Dataverse.
For developers, the Access Checker = a fast debugging shortcut for permission issues when testing customizations or plugins.
Published on:
Learn more