Edit

Share via

Customization Best Practices and Limitations for Project for the web

  • Article

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.

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.

Next Steps