In part one of this mini series within my URS series (I like series, OK?) I suggested a way to use Characteristics with the Scheduling Assistant to help fine-tune your resource results. In this article I suggest another option to that, one that is slightly more complex but also more flexible and applicable to more scenarios.
This is part of a series of articles about Universal Resource Scheduling (URS) and examples on how to customize and use it for custom entities.
What was our scenario again?
So our scenario is still that we need to find skilled Trainers for our Events, but in this case we don’t want to limit our self to creating a few lookups to Characteristics. We want to be able to add as many Characteristics as we want and also be able to add a Rating Value. Let’s get at it!
Creating an intersect Entity
So to start with I’m going to create an intersect entity that connects Characteristics with Event. I use the intersect option instead of a many-to-many relationship (N:N) because I want the user to be able to add a Rating Value of the required Characteristic – so while I’m at it I’ll create a relationship to Rating Value as well.
I’lll add all three new fields on both the Quick Create form and the Main Form of the Event Characteristic entity. My last configuration within Dynamics is to add a subgrid on the Event form and change the label to Trainer Requirements.
Create records from a sub grid with Microsoft Flow
In previous posts I’ve only used classic workflows to create Resource Requirements and all it’s related records that I’ve used for filtering. In this scenario I want to create Requirement Characteristics based on the Event Characteristics records added to my Trainer Requirement subgrid on Event and since that is not possible to achieve with no-code and classic workflows I’ll turn to Microsoft Flow to do the job.
Since Event Characteristics are related records I don’t want to trigger on the creation of Events so I’m going with the “When a record is selected”-trigger on the CDS Connector.
In step 2 I create my Resource Requirement. I use dynamic values from the Event I triggered the flow, most importantly From Date, To Date and the Event lookup.
In Step 3 I use an action called List records. The most important part of this step is to add the Filter Query. This is where I make sure I only list records related to this specific Event. If you’ve never worked with ODATA queries before I would recommend you to read this blog post about it by Sarah Critchley or you can use FetchXML Builder with it’s brand new feature to help with these queries by the amazing Jonas Rapp (he’s my mentor, I have to call him amazing).
Easily explained demo_event_id is the name of the lookup field to Event on my Event Characteristic entity and I want that value to be equal to my dynamic value of Event from my trigger.
Now I have an output with a list of several records I want to loop through and create correlative records for. With the apply to each action I can do just that.
Now we’re all set! Let’s see how it plays out!
So I’ve added a Quick Create form to my Model-driven App just to make registration easier and I’m now able to add as many Characteristics with Rating Value that I need my Trainer to be skilled in.
When I’m done I trigger my Flow by choosing the Flow button in the Command bar and run it.
If I take a look at my Resource Requirement I can see that three records has been created as expected and will therefore filter the Schedule Board in the Scheduling Assistant.
A Tini Tiny Bug to be Aware of
At the moment the Scheduling Assistant does not display any Characteristic Requirement with Rating Values in the Filter view. Please not that its just a matter of visibility, the filtering is still respected. If you add Characteristics without Rating Values there is no issue.
I’ve gotten information that this bug will most likely be solved in Field Service v 8.5 and Project Service v 3.5 so no need to worry.
The Downside with this Solution
In all my previous blog posts about URS I’ve used the classic workflow engine to create Resource Requirements. The main reason for this is that classic workflows can run Real Time and Microsoft Flow can not (not yet anyway). With this solution you need to make sure that you take in consideration that the Resource Requirement will be created asynchronous and therefor create a sustainable process for the users so you do not get data quality issues.
That’s all for now folks!