Personalized Community is here!
Quickly customize your community to find the content you seek.
Check out the latest Field Service updates!Learn about the key capabilities and features of Dynamics 365 Field Service and experience some of the new features.
Download overview guide | Watch Field Service video
2021 Release Wave 2Discover the latest updates and new features releasing from October 2021 through March 2022.
2021 release wave 2 plan
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
It's a bit confusing when to use Teams, Org Units, Territories, Postal Codes etc to divide the Field Service business. Because our Field Service team works mostly in Org units and most of the data displayed should be driven by that. Today Org Unit are ORG visible by security role.
My thought is, what should we use to separate the Field Service Business in the best possible way? Since it will mean that it will affect every view, schedule board, booking and so on, it will be time consuming and would be important to take the right decision here.
For e.g Org Units, then we need to create a relationship to BU to make it restricted by BU level and add some additional js scripts for the "hiding" of the Org units only the the BU related country, then maybe a relationship is also needed to the User table since it's only now connected to Bookable Resource, but both Resources & Dispatcher works in the same Unit so to say and should quickly see their related data.
Any thoughts on how to solve this in a good way? I think one table to divide is enough, doing multiple just really confuses everyone.
Thanks for your input!
I would not use postal codes as a dividing construct.
The most common method for dividing in Field Service if you are not concerned with data access is territories. Resources and work orders both are assigned territories, and schedule boards can be setup by territory as well. So if you don't need to enforce record access, this is the most common.
If you do need to restrict certain access, business units is definitely the way to do. Depending on how complex the organization and how stringent the barriers are, you can also use a combination of business unit and territory so you leave room for users to jump between territories within the same business unit. Happy to give more advice if you would like to provide some more information on the org structure and the security model you are thinking about!
In my experience, Territories is the most common construct to narrow down the number of resources. If the service account is also assigned a service territory and you have your settings correct, it will filter the resources on the territory of the service account. If you want to filter based on the territory of the user, this can be done by modifying the Filter Layout and Retrieve Resources Query in the scheduler as per Alexander Heinze's excellent article. https://www.linkedin.com/pulse/dynamics-365-advanced-user-specific-filter-options-schedule-heinze/ mentione by Dan a few days ago. Alternatively, each Scheduler could just store their filter criteria.
Org Units could also work but are probably at a less granular level. So you would get more resources. They may also be used for different business lines and not for geography (say Laundry vs Catering equipment) if this is the case you need Territory and Org Unit as filter criteria. Or, if they span multiple geographies.
I don't see Postal Codes as very relevant here - today these are far too granular in any of the countries I worked in.
Business Applications communities