What it does

Field Service ships a small set of out-of-the-box Dataverse security roles that map to the app's personas — frontline worker, dispatcher, administrator, inventory manager — plus two IoT roles. They sit on top of ordinary Dataverse table privileges and column-level security, so everything you already know about business units, teams and access levels still applies.

Key facts

• The shipped roles are Field Service - Resource, Field Service - Dispatcher, Field Service - Administrator, Field Service - Inventory Purchase, IoT - Administrator and IoT - Endpoint User.
• Field Service - Resource is deliberately narrow: it lets a frontline worker see and update work orders assigned to them, and nothing more. It also has read-only privileges on addresses, so a technician can't correct a bad service address from the app.
• Field Service - Dispatcher covers scheduling and assignment. Field Service - Administrator is broad access to all Field Service tables and settings, and is meant for IT admins and service managers, not for everyone in the back office.
• Field Service - Inventory Purchase is additive rather than standalone. It layers inventory, purchasing and returns privileges within the user's business unit on top of a resource or dispatcher role.
• IoT - Endpoint User is a system role Microsoft uses to connect Dynamics 365 to IoT systems. Don't assign it to people.
• The schedule board has its own minimum privilege floor, independent of which role you use: Read on BookableResource, Read/Create/Write on BookableResourceBooking, Read on ResourceRequirement, and Read on ScheduleBoardSetting. Miss any of them and users get errors or a blank board rather than a permission message.
• Every Field Service user must hold a security role — a licence alone gets them nowhere. The full chain is user account (Microsoft 365 admin center), licence (Dynamics 365 Field Service or Dynamics 365 Field Service Contractor), membership of the environment, then a role.
• Contractors and vendors are handled as Microsoft Entra B2B collaboration users, added through the Entra admin center rather than created as ordinary tenant users.
• Column-level security profiles are separate from roles. A user can hold a role granting table access and still be blocked on individual columns until they're added to the relevant profile.
• Integration solutions add their own roles. The Business Central integration, for example, installs a Business Central Field Service Integration role that users need on top of their standard Field Service role.

When to use / skip

Use the shipped roles as the starting point on every project, then copy and trim rather than build from scratch. The out-of-the-box roles carry privileges on dozens of msdyn_ tables that you will not reconstruct correctly by hand, and a hand-rolled role is the single most reliable way to produce a blank schedule board two weeks before go-live.

Where you do need to diverge is the middle ground the product doesn't model: the supervisor who should see everything in their region but change nothing, the subcontractor who should see one account's work orders, the back-office user who needs read access to inventory without purchasing rights. Handle those by copying the nearest shipped role and removing privileges, or by adding a small supplementary role alongside the base one. Field Service - Administrator is not the answer to any of them, however often it gets suggested in a workshop.

Configuration decisions

• Which persona each user group maps to, and whether anyone genuinely needs Field Service - Administrator in production beyond the platform team.
• Whether to copy-and-trim the shipped roles or stack a supplementary role on top — stacking keeps you upgrade-safe, copying gives cleaner audit answers.
• How business units and territories relate: whether resources should see work orders organisation-wide, or whether you're using business unit scoping to partition regions or legal entities.
• Whether subcontractors are B2B guests or licensed internal users, and which licence type applies to each.
• Which columns are sensitive enough to need column-level security profiles, and who administers them once the project ends.
• Whether teams (owner or Entra group teams) carry the roles instead of individual assignment, which most clients of any size will want.

Gotchas

• Roles copied from the shipped ones do not pick up privileges added by later Field Service updates. Microsoft updates its own roles; your copy stays where you left it, and features quietly stop working for those users.
• A blank or erroring schedule board is nearly always the four-table privilege floor, not a schedule board configuration fault. Check ScheduleBoardSetting read access first — it's the one people forget.
• The Resource role's read-only address behaviour surprises clients who expect technicians to fix wrong addresses on site. It's by design; changing it means customising the role.
• Assigning Field Service - Administrator to a service manager "just for now" gives them the ability to change Field Service Settings for the whole organisation. That happens more often than anyone admits.
• Licence assignment and role assignment are separate acts in separate portals. A user with a role and no licence, or a licence and no role, both fail, and the error messages point in different directions.
• Integration roles are easy to miss on rollout. Users can log in fine and only discover the gap when they try the one action the integration governs.

Consultant notes

• Build a role matrix — persona, licence type, base role, supplementary roles, teams, business unit — before you configure anything, and have the client sign it. It becomes the go-live checklist and the audit answer at the same time.
• Test with a real user account holding only the intended role, not with your own system administrator account. Everything works when you're a system admin; that tells you nothing.
• Demo the Resource role on a phone rather than in a browser. Clients understand what "only sees their own bookings" means the moment they see the app.
• Before go-live, walk the schedule board, mobile app and one full work order lifecycle as each persona. Permission gaps almost always show up at status transitions rather than on record open.
• If the client asks for a "read-only dispatcher", say yes but budget for it — there's no shipped role, and the schedule board's write requirement on bookings makes true read-only trickier than it sounds.

---

Worth revisiting whenever an integration or add-in goes in, since each one tends to bring roles of its own.