Applies to: Field Service for Dynamics 365 v 6.1 and above, Project Service Automation for Dynamics 365 v 1.1 and above, and Universal Resource Scheduling (URS) solution on Dynamics 365 8.2x and 9.0x
In this blog post, we will review the requirement calendar’s role in creating requirement details, along with the time zone that the pop-out schedule board loads in when using the “book” button.
When creating a resource requirement, each requirement record is associated with a calendar. On the requirement form, there is a “modify calendar” option on the ribbon bar, which allows you to modify the calendar for the requirement.
![Image pointing to the modify calendar button on the ribbon]()
Image pointing to the modify calendar button on the ribbon
![Image showing modify calendar screen]()
Image showing modify calendar screen
This calendar drives two behaviors in URS:
1. Creation of requirement details:
When creating a new requirement, there are several “allocation methods” you can choose from.
![Image showing allocation method options on the requirement form]()
Image showing allocation method options on the requirement form
The calendar has no applicability if I select “none” as the allocation method. However, the allocation methods “Full capacity,” “Percentage capacity,” “Distribute evenly,” and “Front load” all drive logic that contours the requirement duration into many “requirement detail” records. For example, here I will create a requirement and set the allocation method to full capacity from June 1st until June 29th.
You will notice if you navigate to the requirement details related sub-grid, there are requirement detail records generated for 8 hours (480 minutes), with a start time of 9:00 AM. There is a record for most days, but you will notice that it skips June 2nd and 3rd but resumes on the 4th.
![Image showing generated requirement details]()
Image showing generated requirement details
This is because the requirement details are generated using the requirement calendar. Since the requirement calendar is 9 to 5, Monday through Friday, each requirement detail spans 8 hours starting at 9 AM each day, in the time zone set by the requirement calendar. Since June 2nd is a Saturday and June 3rd is a Sunday, there are no requirement details generated for these days since the requirement calendar has both days set as non-work days.
![Image showing requirement calendar]()
Image showing requirement calendar
At the time this article was published, these requirement details are created automatically when a requirement is created, based on the allocation method and the requirement calendar. After they are generated, you can always change the requirement details by using the “Specify Pattern” experience, or by interacting with the requirement details entity directly; you can’t, however, regenerate the requirement details using the logic as if it were initially created.
Now that we explored one way the requirement calendar has an impact, let's explore the other way.
2. Book button pop-out schedule board:
When scheduling from a form or view (as opposed to starting from within the schedule board itself), a pop-out schedule board is launched.
![Image of “Book” button on ribbon of requirement on requirement form]()
Image of “Book” button on ribbon of requirement on requirement form
![Image of “Book” on ribbon of requirement view with one requirement selected]()
Image of “Book” on ribbon of requirement view with one requirement selected
When clicking this book button, the pop-out schedule board loads with scheduling options. But what time zone is the board displayed in? You were not in context of a schedule board before, so we have the ability to launch the Schedule Board in any time zone. Therefore, we load the schedule board in the time zone of the requirement calendar with the logic that you’re likely to want to view the schedule board in context of your requirement’s time zone, since that’s likely to be your customer’s or resource’s time zone.
![Image of Pop Out Schedule Board showing the time zone as Eastern Time]()
Image of Pop Out Schedule Board showing the time zone as Eastern Time, Same as Requirement Calendar
On a side note, the order in which we set the time zone of the schedule board is:
- Requirement calendar
- If there is somehow no requirement calendar or there is somehow no time zone on the requirement calendar, the schedule board will load in the default schedule board’s time zone.Now that we have explored where the requirement calendar has impact, let’s explore how the requirement calendar is configured, along with its schema.
- When creating a new requirement, there is a field on the requirement entity (hidden on the form by default) where you can set a work hours template (msdyn_workhourtemplate). If you set a value in this field, the requirement calendar will be based on this work hours template. As a result, the requirement details will be generated according to the template, and the pop-out schedule board will be loaded in the time zone for this template (since those values are set on the requirement calendar). This gives system customizers a way to build business logic where you can set the work hours template field based on whatever logic you choose, through workflows, plugins, etc.
![Image of resource requirement form with work hours template field displayed]()
Image of resource requirement form with work hours template field displayed
- If you do not set the work hours template field on the requirement, the calendar is automatically created as 9 to 5, Monday through Friday, in the time zone defined by the user’s personalization settings.
![Image of time zone setting in Dynamics 365 personalization settings]()
Image of time zone setting in Dynamics 365 personalization settings
- Once a requirement is created and a calendar is created, the requirement is associated to its unique calendar through an attribute on the requirement entity called “Calendar ID” (msdyn_calendarid). This attribute is a string field and contains the guid of the Calendar instance for that requirement. This field is also not exposed on the form by default. Now that you know how the requirement is related to its calendar, customizers have more power to interact with the requirement calendar.
![Image of Calendar ID field exposed on the requirement form]()
Image of Calendar ID field exposed on the requirement form
Happy scheduling!
Dan Gittler
Principal Program Manager, Dynamics 365 Engineering
![clip_image001[6]](http://msdnshared.blob.core.windows.net/media/2018/06/clip_image0016_thumb.png "clip_image001[6]")
![clip_image001[8]](http://msdnshared.blob.core.windows.net/media/2018/06/clip_image0018_thumb.png "clip_image001[8]")
.
