How Booking Alerts work in Dynamics 365 – Field Services

Booking Alerts in Dynamics 365 – Field services is an activity type with one speciality, which is its ability to show in the schedule board. Booking Alert is actually an effective alert for the Dispatcher who is working with the schedule board.

Booking Alert is created in two entities those relates as below;

Let’s see standard Booking Alert form;

Most of the fields here are obvious and standard for activity types, but two marked ones are special. Idea of them are as follows;
Due date – This Due date is the date/time this Alert will be pop-up in the schedule board. This should be a future date.
Assignees – These are the users who need to be logged in to see the Alert. My opinion these ones should be the Dispatchers in typical Field Service implementation.

Let’s see behind the scene how Booking Alert Status records being populated. Next time to show field is nothing but the Due Date of the parent record.

Caution: Once created don’t change the Due Date in Booking Alert without changing these values in Associate records (this doesn’t update automatically).

Here we see our Booking Alert.

Let’s see what actions user (i.e. Dispatcher) can perform now.

1) Dismiss
Once user click Dismiss, alert will disappear. What happen behind the scene is Status of the Booking Alert Status record becomes Inactive. This is specific to user. In our example if Dismiss is clicked by Jamie Reding, Spencer Low will still see the alert because his record is still Active.

2) Snooze 
Snooze allows user to set alert to pop-up later. (ex. 15 mins). What happen here is Next Time to show field of Booking Alert Status record get updated with next pop-up time.

Get Form Type in Business Rules

There is no proper way of identify if form is in CREATE or UPDATE. This seems a big missing piece when it comes to implement field functionalities especially for Form Scopes.

Dynamics 365 (Version 8.2 or earlier)

One passive way of doing that is to check if Create On field contains data.

1) Created On - Not Null - Update
2) Created On - Null - Create

Using Create On is particularly sensible since that field is not set with on Load event even by chance.

Dynamics 365 (Version 9)

Then I realise above solution does't work for Version 9. Then found a way to do it slightly differently.

Instead of Created On, we have select a required field to check value to decide if its created or not.

Suppose we need to lock the Department field of Contact after creation.

1) Set Department field as Read-Only in the form.
2) Now do the Business Rule using one of the Required Fields such as First Name.