Dynamics 365 Project Operations Task Grid Access Controls: Configure Read, Full, and Custom Permissions

Trackable under roadmap ID 576804, this capability entered public preview in May 2025 and reached general availability in August 2026 for Worldwide (Standard Multi-Tenant) web environments, marked as Launched and enabled for end users automatically once turned on in feature control settings. According to Microsoft Learn documentation updated in September 2026, the access control model applies to both Project Operations Integrated with ERP and Project Operations Core deployments.

Why the Embedded Task Grid Needed a Bouncer​

To understand why this update matters to Dynamics 365 administrators and project management offices (PMOs), it helps to look under the hood of how Project Operations renders project plans. As noted in Microsoft Learn's task grid troubleshooting documentation, Dynamics 365 Project Operations presents the task grid as a hosted iFrame inside Microsoft Dataverse that communicates with an external scheduling service.

In a typical enterprise environment, dozens of stakeholders—from finance auditors and sales account managers to department executives—need visibility into a project record. They need to inspect schedules, verify milestones, or review resource utilization. However, prior to this feature, granting a user access to open a project record meant the embedded Project for the web iFrame allowed unrestricted modifications to tasks, dependencies, and goals. An accidental drag-and-drop or a well-meaning edit by a casual observer could quietly ripple through the work breakdown structure.

Why should an executive reviewing a quarterly timeline have the same destructive editing power as the lead scheduler? With task-grid access restrictions enabled, administrators and project managers can finally separate the right to view a project schedule from the right to alter it.

Section Summary:

• The Old Behavior: Opening a project record allowed unlimited changes inside the embedded Project for the web iFrame, including creating, editing, and deleting tasks, dependencies, and goals.
• The Update: Roadmap item 576804 introduces a two-tier permission system governing task-grid actions for non-team system users and assigned project team members.
• Deployment Scope: Available on the Web platform for Worldwide (Standard Multi-Tenant) cloud instances across both Project Operations Integrated with ERP and Project Operations Core.

How the Two-Tier Permission Model Works​

Microsoft's access control architecture splits governance cleanly between global administrators (who manage users outside a project team) and project managers (who manage resources actively assigned to their projects). Both tiers enforce restrictions directly at the task grid level.

1. System User Level (Non-Team Members)​

When a user opens a project record without being a member of that project's team, their capabilities inside the task grid are governed by their System user settings. Microsoft Learn documentation specifies two permission states at this level:

• Read only (Default): The user can view the task grid inside the project record but cannot make any changes.
• Full access: The user can perform all Create, Update, and Delete operations on the task grid even when they are not listed as a project team member.

Because Read only is the default for all users at the system user level once the feature is active, casual project visitors and cross-departmental observers are automatically prevented from making accidental edits. Conversely, if an organization has a PMO director or an executive sponsor who routinely steps into multiple projects to adjust schedules without formally joining every project team, an administrator can elevate that specific user to Full access at the system user level.

2. Project Team Member Level (Assigned Resources)​

For resources who are part of a project team, project managers can tailor permissions on a project-by-project basis. By default, all project team members receive Full access, preserving the collaborative workflow for active contributors. However, project managers can override that default with three options:

• Read only: The team member can view the schedule in the task grid but cannot modify anything.
• Full access (Default): The team member can perform all Create, Update, and Delete task operations.
• Custom: The project manager can individually toggle Create, Update, and Delete permissions for tasks.

Consider a practical real-world scenario: a senior developer on a client rollout needs to update task progress or adjust task details (Update enabled) and perhaps break a deliverable into sub-tasks (Create enabled), but the project manager wants to ensure no team member accidentally wipes out existing milestones (Delete disabled). Using the Custom access option at the project team member level makes this exact combination straightforward to enforce.

Section Summary:

• Non-Team Users Default to Safe Mode: System users outside a project team default to Read only on the task grid, with an option for administrators to grant Full access.
• Team Members Default to Collaborative Mode: Project team members default to Full access, but project managers can restrict them to Read only or apply Custom permissions.
• Granular CRUD Control: The Custom tier at the team-member level lets project managers independently permit or block task creation, updates, and deletion.

Step-by-Step Configuration Guide for Administrators and PMs​

According to Microsoft's official documentation on task-grid access control, setting up these restrictions requires no code and is handled directly from the Action Pane in Dynamics 365 Project Operations.

Configuring Access for Non-Team Users (System User Level)​

1. Navigate to the System user page for the target resource.
2. On the Action Pane, select Project user permissions.
3. In the Project user permissions dialog box, locate the Access Level field and select either Read only or Full access.

Configuring Access for Assigned Team Members (Project Team Member Level)​

1. Open the Project Team Member page, where the Access Level field displays the resource's currently assigned permission type.
2. To adjust the setting, go to the Action Pane and select User permissions.
3. In the Set Permission dialog box, choose Read only, Full access, or Custom in the Access Level field.
4. If you choose Custom, a Permissions grid will appear inside the dialog. Select Edit to launch the Project Team Member Permission page, where you can individually configure the Create, Update, and Delete task permissions.

Critical Deployment Check: Custom Security Roles and Entity Privileges​

If there is one operational trap that frequently catches Dynamics 365 administrators off guard during a security rollout, it is custom Dataverse security roles. Out-of-the-box security roles generally receive schema updates automatically, but enterprises relying on custom-built roles must manually grant privileges to newly introduced permission tables.

Microsoft Learn explicitly warns that if your organization assigns permissions via custom roles, users might lose access to the project plan entirely unless those custom roles are updated with privileges for two specific access-control entities:

(Note: Verify the exact schema name spelling in your environment, as Microsoft's official documentation lists the second entity spelled as msdyn_projetteampermission with a single 'c'.)

Before enabling or relying on task-grid access restrictions in production, IT administrators should audit every custom security role assigned to project viewers, contributors, and project managers. If a user reports that the embedded Project for the web iFrame fails to load the plan after this feature is turned on, missing Read privileges on msdyn_useraccesspermission and msdyn_projetteampermission should be the very first troubleshooting checkpoint.

Section Summary:

• Simple UI Controls: Permissions are managed via Project user permissions on the System user page and User permissions on the Project Team Member page.
• Custom Role Warning: Custom security roles that lack permissions on the underlying access-control entities can cause users to lose access to the project plan.
• Mandatory Entity Rights: All task-grid viewers need Read access to msdyn_useraccesspermission and msdyn_projetteampermission, while permission managers require full Create, Read, Write, Append, Append to, and Delete rights on both.

Practical Boundaries and What Admins Should Test Next​

While this update significantly tightens schedule governance, administrators should keep its architectural boundaries in mind. The controls documented by Microsoft specifically govern operations inside the task grid—namely creating, updating, and deleting tasks. They are not a replacement for overarching Dataverse record-level security, business unit hierarchies, or project financial approvals.

To ensure a smooth transition without disrupting active delivery teams, Dynamics 365 administrators and PMOs should consider a brief validation pass:

1. Audit Custom Roles First: Confirm that msdyn_useraccesspermission and msdyn_projetteampermission privileges are added to all relevant custom security roles before enforcing restrictions.
2. Identify Power Users Outside Project Teams: Because non-team users default to Read only at the System user level, identify any resource managers, PMO staff, or executives who legitimately edit project task grids without being added as team members, and switch their Project user permissions to Full access.
3. Brief Project Managers on the Custom Tier: Let project managers know that their team members still default to Full access, and show them how to use the User permissions button on the Project Team Member page if they want to lock down task deletion or restrict external contractors to read-only schedule visibility.

By separating casual project inspection from active schedule editing, Dynamics 365 Project Operations gives project managers the confidence that their carefully constructed task grids won't be rewritten by a passing observer. Have you rolled out task-grid access restrictions in your Dynamics 365 environment yet, or run into custom security role hiccups along the way? Share your deployment experiences in the WindowsForum.com enterprise administration discussions.