Project for the web (New Microsoft Planner) is Microsoft’s most recent offering for cloud-based work and project management. It is included in the New Planner Premium version and it includes Copilot. Project for the web provides simple, powerful work management capabilities to meet most needs and roles. Project managers and team members can use Project for the web to plan and manage work of any size.
Microsoft Project for the Web Platform
Project for the web is built on the Microsoft Power Platform. The Power Platform consists of PowerApps, Power Automate, Power BI, and the Microsoft Dataverse. Project for the web data is stored in the Microsoft Dataverse.
Integration with the Microsoft Power Platform lets you easily use its components to create custom business solutions and do advanced analytics and reporting on project data.
Just like Project Online, users can access their Project for the web projects through the Project Home page. It will by default list projects that were recently viewed, owned by, or shared with the user.
Dataverse lets you securely store and manage data that’s used by business applications. Data within Dataverse is stored within a set of tables.
A table is a set of rows (formerly referred to as records) and columns (formerly referred to as fields/attributes).
Each column in the table is designed to store a certain type of data, for example, name, age, salary, and so on.
Dataverse includes a base set of standard tables that cover typical scenarios, but you can also create custom tables specific to your organization and populate them with data by using Power Query.
App makers can then use Power Apps to build rich applications that use this data.
Levels of access management in Power Platform (Dataverse)
There are three main levels of access management in Power Platform: environment, app and data level.
Environment level access
- The security group ensures only people with this security group can access the environment
- If not used, all users from the Active directory can be added to projects and access is granted automatically to projects created in the environment.
App level access
Security Roles are used to give Rights at the app table level
Data level access
At the data level of access, information can be restricted at Column level (Create, read, delete, write…)
1.1.2. Security model components in Dataverse
There are a few important components that together make the security model: business units, security roles, teams and field(column) security profiles.
1.1.2.1. Business Units
Business Units are the foundation of the security model that control access to data. For example, a company can have two main groups: North America and International. They should see different data based on where they report to. And Management should see everything. This can easily be accomplished by creating separate business units.
Business units will control who has access to data.
1.1.2.2. Security Roles
A security role consists of record-level privileges and task-based privileges of the following three types:
- Tables: Table privileges define which tasks a user with access to a table record can do, such as Read, Create, Delete, Write, Assign, Share, Append, and Append To. Append means to attach another record, such as an activity or note, to a record. Append to means to be attached to a record.
- Miscellaneous privileges: These task-based privileges give a user permission to perform specific, miscellaneous (non-record) tasks, such as publish articles or activate business rules.
- Privacy-related privileges: These privileges give a user permission to perform tasks that involve data that’s integrated, downloaded, or exported outside of Dataverse, such as exporting data to Microsoft Excel or printing
Security roles are given to Teams or Users and allow for permissions at the table level. A user can have multiple security roles. Security role privileges are cumulative. Users are granted the privileges that are available in each role that’s assigned to them.
The following table describes the table privileges you can grant in a security role. In all cases, which records a privilege applies to depends on the access level of the permission defined in the security role.
| Privilege | Description |
| Create | Required to make a new record |
| Read | Required to open a record to view the contents |
| Write | Required to make changes to a record |
| Delete | Required to permanently remove a record |
| Append | Required to associate the current record with another record; for example, if users have Append rights on a note, they can attach the note to an opportunity In the case of many-to-many relationships, a user must have Append privilege for both tables being associated or disassociated. |
| Append to | Required to associate a record with the current record; for example, if users have Append To rights on an opportunity, they can add a note to the opportunity |
| Assign | Required to give ownership of a record to another user |
| Share | Required to give access to a record to another user while keeping your own access |
Access levels
Each privilege has a menu that allows you to define its access level. Access levels determine how deep in the business unit hierarchy the user can perform the privilege.
The following table describes the levels of access. For organization-owned tables, miscellaneous privileges and privacy-related privileges only have access levels of Organization or None.
| Type | Description |
| Organization | Users can access all records in the organization, regardless of the business unit hierarchical level they or the environment belong to. Users with organization access automatically have all other types of access as well. Because this level gives access to information throughout the organization, it should be restricted to match the organization’s data security plan. This level of access is usually reserved for managers with authority over the organization. |
| Parent: Child Business Unit | Users can access records in their business unit and all business units subordinate to it. Users with this access automatically have business unit and user access. Because this level gives access to information throughout the business unit and subordinate business units, it should be restricted to match the organization’s data security plan. This level of access is usually reserved for managers with authority over the business units. |
| Business Unit | Users can access records in their business unit. Users with business unit access automatically have user access. Because this access level gives access to information throughout the business unit, it should be restricted to match the organization’s data security plan. This level of access is usually reserved for managers with authority over the business unit. |
| User | Users can access records they own, objects that are shared with the organization, objects that are shared with them, and objects that are shared with a team that they’re a member of. This is the typical level of access for sales and service representatives. |
| None | No access is allowed. |
The colored circles on the security role settings page identify the access level assigned to each privilege. Access levels determine how deep in the business unit hierarchy the user can perform the privilege.
The following table describes the levels of access.
| Icon | Description |
| Global. Users can access all records in the organization, regardless of the business unit hierarchical level they or the environment belong to. Users who have Global access automatically have Deep, Local, and Basic access. Because this level gives access to information throughout the organization, it should be restricted to match the organization’s data security plan. This level of access is usually reserved for managers with authority over the organization. The application refers to this access level as Organization. | |
| Deep. Users can access records in their business unit and all business units subordinate to it. Users who have Deep access automatically have Local and Basic access. Because this level gives access to information throughout the business unit and subordinate business units, it should be restricted to match the organization’s data security plan. This level of access is usually reserved for managers with authority over the business units. The application refers to this access level as Parent: Child Business Units. | |
| Local. Users can access records in the user’s business unit. Users who have Local access automatically have Basic access. Because this access level gives access to information throughout the business unit, it should be restricted to match the organization’s data security plan. This level of access is usually reserved for managers with authority over the business unit. The application refers to this access level as Business Unit. | |
| Basic. Users can access records they own, objects that are shared with the organization, objects that are shared with them, and objects that are shared with a team that they’re a member of. This is the typical level of access for sales and service representatives. The application refers to this access level as User. | |
| None. No access is allowed. |
Figure 4 Security role
1.1.2.3. Teams
Teams created in Power Platform, gives users the ability to see data across business units. Teams have assigned security roles to them. While a team belongs to one business unit, it can include users from other business units. A user can be associated to more than one team.
Teams can be owner or access teams.
Owner Team: Owns records and has security roles assigned to a team. Team members are added manually. Most implementations use this type of team.
Access team: does not own records, no security roles assigned to a team. Records are shared with an access team, and the team is granted access to Read, Write or Append to records. Typically used when team members change often.
1.1.2.4. Column Security Profile
Column security profile is the way to do lock down visibility of specific fields to certain user groups.
There are two steps to implement column-level security:
- Enable field security on a field (column) within an entity (table).
- Associate an existing security profile(s).
1. Security roles (eg. PA_Project Managers) are created in Dataverse and permissions are assigned to tables (eg. Project, Project tasks…)
2. Teams are created in Dataverse and assigned to security roles (e.g. Project Managers)
3. Users are added to teams (Project Managers)
1.1.3. Security roles in Power BI
In addition to Dataverse permissions Power BI has different permissions requirements, summarized as follows:
▪ Power BI reports deployed must be shared with all users requiring access
▪ A Power BI workspace / app can be shared with SharePoint Groups/Teams or SharePoint Security only groups
1.1.4. Sharepoint Access
SharePoint document management requires that all users be granted access to the SharePoint Group (or Team) storing the documents
1.1.5. How Access rights are given within the solution
Within the Project for the Web + Accelerator solution, the following working steps are utilized:
- PM creates a new Microsoft Teams Group and add members (existing members are from Azure Active Directory, synchronized already with Microsoft Teams)
- PM utilize the Project Accelerator App to create a new project (eg.: “Project X”)
- PM can add all required info. For the project (financials, risks…)
- PM creates the task schedule and selects the existing Microsoft Teams Group for communication
- After the Project for the Web schedule is created and attributed to the Microsoft Teams Group, a new Team group is created within Power Platform, as this is synchronized with Azure Active Directory (Entra ID) . The syncronyzation is being done at the Business Unit enterprise level with security roles.
Figure 5 Permissions and security models in Project for the Web and Project Accelerator
1.2. Configuration of Microsoft licenses (CLIENT)
| Security profile | Security requirements | License requirements | Security roles Power Platform |
| Executives | Read access to everything | ||
| PMO | Read/write access to everything (portfolio oversight) | Project Plan 1 Power Apps Power Bi Pro | Project User – tenant level |
| Project Managers | Read/write access to own projects within Power Apps and Power BI (Create project plans, tasks) | Project Plan 3 Power Apps Power Bi Pro | Project User – Business Unit level |
| Team Members (read/write) | Read/Write Access to Project and Power Apps | Project Plan 1 Power Apps | Team Member -Tenant Level |
| Team Members only task updates | Update assigned tasks within Project for the Web | Microsoft 365 subscription under organization tenant | Team Member Tenant level |
| Guest user (view only) | Access to view schedule and related files | Team Member Busines Unit level | |
| Guest users ( task updates) | Acess to view/write/and update schedule | Project P1 minimum within organization tenant | Team Member Busines Unit level |
Project for the Web and Project Accelerator Implementation Plan
The following is a high-level overview of the implementation plan:
Overall schedule
| 1 | Project for the Web Accelerator Implementation CLIENT | |||
| 1.1 | 1. Consultation | 8 | Deliverable: Document capturing CLIENT requirements/configuration for P4W – Accelerator | Walkthrough of Project for the Web (P4W) – Accelerator solution and customization options and engagement with CLIENT to clarify the CLIENT needs and expectations. |
| 1.2 | 2. Pilot Implementation | 51 | Deliverable: Working P4W – Accelerator environment in CLIENT Microsoft suite. | Configure, implement, and test Microsoft P4W – Accelerator working environment and licenses including roles/access rights, connections to Power BI, and preparation of guidance material. |
| 1.3 | 3. Training | 13 | Deliverable: At least two online training sessions covering the relevant topics. | Provide CLIENT project managers and IT team members with training on a) Project Planning and Control with MS Project for the Web Accelerator solution, and b) project reporting with Power BI |
| 1.4 | 4. Support | 0 | Provide additional post go-live support as-needed. | |
Future Developments
While Microsoft continues to develop Project for the Web, organizations requiring more advanced access control and project management features might consider using the full Microsoft Project Online application instead of Planner.For the most up-to-date information on access rights management in Project for the Web, it’s recommended to consult the official Microsoft documentation or contact Microsoft support directly.
FAQ
Frequently Asked Questions: Access Rights for Microsoft New Planner and Project for the Web
General Questions
Q1: What is the difference between New Planner and Project for the Web?
A: The New Planner is an updated version of Microsoft Planner that will incorporate features from Microsoft To Do and Project for the Web. Project for the Web is a more robust project management tool that offers advanced features like resource management and task dependencies.Q2: How does access management differ between New Planner and Project for the Web?
A: Both rely primarily on Microsoft 365 group membership for access control. However, Project for the Web offers more granular control through licensing options.
Access Rights and Permissions
Q3: How are access rights managed in Project for the Web?
A: Access is primarily controlled through Microsoft 365 group membership. Administrators can also manage access at the organizational level or for individual users through license assignment.Q4: Can I set up role-based access control (RBAC) in New Planner or Project for the Web?
A: Currently, there is no built-in RBAC system for either tool. Access is generally an “all or nothing” approach within a plan or project.Q5: How do I control who can edit projects in Project for the Web?
A: Users with access to a project generally have full edit rights. There’s limited ability to restrict specific actions within a project.
Licensing and Access
Q6: What licenses provide access to Project for the Web?
A: Project for the Web is available through Project Plan P1, P3 (formerly Project Online Professional), and P5 (formerly Project Online Premium) licenses.Q7: Can external users access Project for the Web?
A: Yes, external users can be invited as guests to the associated Microsoft 365 Group. However, they will have limited access and functionality unless assigned a license.
Comparison with Project Online
Q8: How does access management in Project for the Web compare to Project Online?
A: Project Online offers more advanced access control features, including the ability to create custom security groups and set granular permissions at various levels (project, resource, view, etc.).Q9: Can I use the same access control methods from Project Online in Project for the Web?
A: No, Project for the Web has a simplified access model compared to Project Online. Many of the advanced permission settings available in Project Online are not present in Project for the Web.
Administrative Control
Q10: How can administrators control access to Project for the Web?
A: Administrators can turn Project for the Web on or off for the entire organization or for specific users through the Microsoft 365 admin center.Q11: Can I restrict certain features of Project for the Web for some users?
A: Feature restriction is primarily controlled through licensing. Administrators can assign different license types (P1, P3, P5) to control feature access.
Future Developments
Q12: Are there plans to improve access rights management in New Planner or Project for the Web?
A: While Microsoft continually updates its products, there are no officially announced plans for major changes to access rights management as of now. It’s best to check the official Microsoft 365 Roadmap for the most up-to-date information.Remember, for the most current and detailed information, always refer to the official Microsoft documentation or contact Microsoft support directly.