Imagine going to work desk (aka kitchen top for me) in the morning and finding a new gadget, stationary item or something useful. Dynamics 365 is a little like that, recently — with a stream of enhancements and new features (big and small) are arriving subtly as part of Dynamics 365 product updates, Power Platform updates, and Dataverse enhancements. One recent one is ‘Check Access’.
It must have been part of Release Wave documentation but somehow I lost track of it until I saw this new button on every form. Clicking on it, brings up a form that shows all the permission logged-in user has related to the form/table. Furthermore you can also select any other user to check that user’s permissions on the same form/table. Slick, easy and useful!
Dynamics 365 Field Service, like its other Dynamics 365 siblings, comes with a bunch of security roles and field security profiles. These out-of-the-box security configurations are then updated and tailored in each implementation. This article is to have a look at these roles & profiles, and briefly touch upon associated best practices:
Every discussion on security architecture & setup of a new system starts with the identification of personas. Personas are the categories of users who have the same objectives to use the system, require similar data access and work on the same or similar position in an organisational hierarchy. Identification of personas, generally, helps in aligning the “security setup” of the system in alignment with these categories.
The out-of-the-box security configurations of Dynamics 365 Field Service is based on 8 personas – these don’t need to be separate individuals as each user can have multiple roles. Also, it is quite common to drive further custom roles from these roles. In fact, one of the key best practice is to:
Pro Tip! Always make a copy of out-of-the-box Security Role before making any changes to it
Following are the roles and field security profiles in Dynamics 365 Field Service:
Persona
What do I do?
Security Role
Field Security Profile
Dispatcher
I work in D365 web (back-end user) to plan and schedule resources against work orders. In doing so, I am an owner of service management in the system
Field Service – Dispatcher
Field Service – Dispatcher
Resource
I work in D365 mobile app on booked work orders against me (as a resource)
Field Service – Resource
Field Service – Dispatcher
Inventory Purchase
I work in warehouses and stores to setup “Product Catalog” and manage inventory. I am also a backend user (D365 web)
Field Service – Inventory Purchase
Field Service – Inventory Purchase
Salesperson
I work in the sales function of a Field Service organisation
Field Service – Salesperson
N/A
Business Administrator
This could be a functional role, assigned to any power user or in IT
Field Service – Administrator
Field Service – Administrator
In addition, there is an additional security role – Time Entry User – which should be assigned to resources in order for them to be able to add or update time entry records.
So, to summarize…
Security setup in Dynamics 365 Field Service should not be underestimated. This may sound trite but unlike other Dynamics 365 products, the security model of Dynamics 365 Field Service is considerably more complex because of significantly more related tables (if you create a Work Order, you’ll also have to create Resource Requirement etc.), the dependency of Configuration data (Work Order Types, Incident Types etc.) and multiple interfaces (web vs mobile – and also possibly Power Apps portal). I have seen those projects struggle (or fail!) when security discussions are left till the end. Ideally, personas leading to roles and field security profiles should be discussed early on as part of the Analysis & Design phase of all projects.
Thanks for reading!
Feel free to share your feedback, I’d love to hear your thoughts 😊
