Mar 9, 2018

Cannot Delete Entity – Invisible Form Dependency

Once we remove all the possible dependencies for an Entity, we are allowed to Delete it in Dynamics 365. Once in a while it doesn’t behave as expected. I faced one such case recently.  Though I removed every possible/visible dependency, I couldn’t delete the Entity (say Region, new_region). It shows me some more Form dependencies.

In such case, what you need to do is create a Temporary Solution and add only the Entity that Form belongs to, Import it, Unzip and Open Customization.xml in readable editor. Now search for the Entity Schema name (i.e. new_region) you need to delete. Most probably, you will find section like below.

This means dependency is on one of the Filter of lookup fields within that Form. If you browse to the customisation of that Form you will see particular Lookup Filter is not even enable. My hunch is, previously this Lookup filter may have been configured to filter by the relationship with the entity we are going to delete. This <DependentAttributeType> tag may not have been removed once disabling the Filter of the lookup or even when deleting the relationship.

How to Fix
Enable the Lookup filter and set a different filed (ex. By Owner) and publish. Then this troublesome tag will be replaced with this new type. Now we can delete our Entity. Now you can disable the Filtered lookup as necessary.

Feb 23, 2018

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.

Dec 13, 2017

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. Then only I came to know that passive way of doing that is to check if Create On field contains data.

Create On - Not Null - Update
Create On - Null - Create

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

Hope this is cool.