1,380
Like
Share
Report
This article is part of a series on Field Service for Beginners
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:
The ‘Whats’ and ‘Hows’
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 
Say hi on Twitter and subscribe here if you’d like to get my new posts (on Dynamics 365, Azure AI and IoT) via email (roughly weekly).
*This post is locked for comments