Customization Best Practices and Limitations for Project for the web
Microsoft Project for the web will soon become Microsoft Planner, which is currently rolling out to customers. To learn more about setting up the new Planner for your organization, see Microsoft Planner for admins.
Note
Most changes to the Project Power App can be made with only the System Customizer security role. Some changes such as configuring the Option Set require that you have privileges that are part of the System Administrator security role. Learn more about Project Power App security roles.
Tip
Make all changes to the Project Power App inside of a new solution. This will make it easier to backup and deploy any changes you make. Learn more about solutions.
Prerequisites
- Admin rights in a development environment with Project for the web
- An understanding of managed solution layers
- (Optional, but recommended) A Developer plan so you can export your solution to easily deploy in other environments
General best practices
Always create a managed solution that contains your customizations, so you can layer them on top of the Project solution.
Use the Power Apps portal to make easy changes. If you find you need to do something and can't find a way in the Power Apps portal, use the Power Apps solution explorer, which provides more advanced options.
To avoid errors during importing your solutions, ensure your solution does not attempt to modify locked properties within the Project solution.
General limitations
- Except for creating a new project, creating records and editing fields in the project tables requires the Project scheduling API.
- If you decide to duplicate and modify Project security roles, you'll need to update those roles whenever there are new releases of the Project solution. For example, the Task History feature added new tables to the Project solution. Your custom security roles must have the same permissions to those tables as the Project security roles, otherwise users with your custom security roles won't be able to use the Task History feature.
Use Teams Group and roles to implement security and access
Although you can as an admin create users and assign security roles in the Microsoft Power Platform, when you want to customize the Project solution, you should avoid this practice. Project for the web security leverages Teams Groups, so you should instead manage group teams and assign security roles to teams whenever you can, instead of granting individual users security roles.
Examples of what is and isn't supported
✅ Supported: Customizing security roles so that users can't edit specific custom columns added to tables in the Project solution.
❌ Not supported: Customizing security roles so that users can edit projects, but not create new projects.
Don't restrict access to existing Project entities using Dataverse security
You might be tempted to create restrictions on tables that are part of the Project solution using Dataverse security. This is a bad idea, as the components of the Project solution require access to the Project entities and use Teams Groups security roles to control access.
However, you might want to restrict access to new tables and columns that are part of your custom solution. Although it's best to use Teams Groups Security to control access to tables, column security for new columns is most easily done by setting a column property. In new columns, Dataverse column security may be appropriate.