Currently I’m in a project where our team is going to roll out Dynamics 365 Project Service Automation for one of our customers. Throughout the project, we’ve learned a lot about this new cool kid on the block 🙂
Some gotchas/lesson learned when we are rolling out this to the customer:
- Choose Project Template carefully. Once created, the user can’t change the project template and need do it again from the scratch (not a big hassle, but definitely I mentioned this when during the training).
This is for Admin/Customizer, PSA-related controls limitation. Time Entry & Expense, WBS, schedule board, etc. They are pretty much static (hard coded), it is not honoring relabel, adding more options and even can’t add any new field. Seems like we need to treat PSA in a similar manner to other ISV solution, such as Click Dimensions, (compared to Sales/Service/Marketing that have more mature customization and configuration flexibility).
Pay attention to “metadata” records (Resource Role, Resource Skill, Price List, Expense Categories, etc) during deployment. Similar to Adx/portal scenario, where records are stored as configuration. To have ALM for PSA correctly, will need to pay attention to those records as part of the deployment process.
One of the biggest catch that I’ve got: can’t undo approval. Approvers need to be really really careful with their approval.
For this instance, I submitted an idea entry: https://crmideas.dynamics.com/ideas/dynamics-crm/ID0000986. From the feedback from the 2 customers that we have worked with, they need this feature to make an amendment to the entries, at least before it is processed for invoice (at least a flag or something to cater this scenario).
- Data migration is a bit tricky, for some scenarios, we’ve got to deactivate some of the validation plugins to let the data in (need to have thorough testing on this, as I consider this as touching the OOTB process that is not well documented).
Hope this helps!