Execute a Recurring Job in Microsoft Dynamics 365 with Flow

I have written about executing recurring jobs in Dynamics 365 few times in the past. Over time, I suggested different scheduling mechanisms such as Microsoft Dynamics Workflow Timeout step or Azure Scheduler, as the pattern I suggested allows changing the scheduling mechanism without impacting other solution parts.

Asynchronous Batch Process Pattern

Flow can be also used as a scheduling mechanism, one that does not require coding like Azure Function,  as it has a built in integration with Microsoft Dynamics 365 Online.
Once invoked on schedule, the executing component query Dynamics 365 for target business records and apply some business logic (Process) to each business record.

In this post I would like to demonstrate a solution for executing a recurring job in Microsoft Dynamics 365 using Flow as the scheduling component.

Sample business requirement

Weekly Leads Evaluation: once a week, disqualify all Leads that are more than 5 days old and are not rated ‘Hot’.
Add a note to each Lead record to indicate that it was disqualified by an automated process.

Walkthrough

  1. Download, Import and publish the ABP unmanaged solution.
  2. Create the Action component: Disqualify Lead Workflow

    This Workflow Rule will be applied to each valid target business record. It simply attaches a Note and changes the Lead record state to Disqualified. It can be a/synchronous, but you may want to start with a asynchronous execution to monitor the process execution.
    Make sure you define the process as an on-demand process with no automated triggers.

    Create the Action component: Disqualify Lead Workflow

  3. Define Target Business Records Query

    Using the Advanced Find, define a new query to retrieve all Lead records where Created On date is older than 5 days and are not rated ‘Hot’.
    Click to Edit Columns button and remove all possible columns to maximize the query efficiency.
    Click the Download Fetch XML button and open the resulting file with some text editor. Copy the FetchXML query text to the clipboard

    Define Target Business Records Query

  4. Create a Batch Process Record

    This record is used to orchestrate by holding a FetchXML query to define the target business records and also the Action process which will be applied on the the target business records.
    If you imported an unmanaged solution, find the Batch Process entity and set it to appear in the Settings area.
    Create a Batch Process record and paste the FetchXML query text into the Target Records textbox.
    Name the record ‘Weekly Leads Evaluation Process’.
    Select the Disqualify Lead Workflow (created in step 2) in the Process Lookup field and save the record.
    Copy the Reference Token value for the next step.

    Create a Batch Process Record

  5. Define Flow Rule

    In your tenant, navigate to the Flow area and create an empty Flow named Weekly Leads Evaluation.
    Define a Recurrence Trigger to trigger the batch process

    Define a Recurrence Trigger to trigger the batch processDefine a Recurrence Trigger to trigger the batch process

    Next, define a List records action.
    In the Filter Query text box, paste the Batch Process Reference Token value and precede it with dyn_referencetoken eq (e.g. dyn_referencetoken eq ‘LOGY8Y1W6’).

    Next, define a List records action

    Define Update record action which will automatically wrap it with Apply to each wrapper. Add a Condition before the Update Action to verify that the Flow operates only if the Batch Process record status is Scheduled. 

    Define Update record action which will automatically wrap it with Apply to each wrapper

  6. Activate

    Change the Batch Process record status to Scheduled and save.
    Activate the Flow Rule.
    You can monitor the Flow activation by navigating to the Run History area.

    You can monitor the Flow activation by navigating to the Run History area

    For each run, you can see the completion status (success/failure) and failure reason

    For each run, you can see completion status (success/failure) and failure reason

Similarly, you can now add additional scheduled batch processes. 

Implementation Details

Advertisements

Animated Tip: Create a Fully Functional Portal Page in 60 Sec. (Or Less)

The Create Portal Content wizard is a nice new feature in Portal version 8.3 that was published recently. This wizard simplifies the process of creating webpages along with entity forms and entity lists by admins.

If you are not familiar with the process of provisioning new pages in Microsoft Dynamics 365 Portal, you can do some reverse engineering of the Portal elements automatically created by the wizard.

In the following demo, I am creating a new Page for authenticated Portal users which displays Lead records with an option to create new record. It assumes that the user has the required Entity Permission for the Lead entity.

Click here to view a larger version of this animated tip

creating a new Page for authenticated Portal users which displays Lead records with an option to create new record

Customization Aware Web Resource – Part 1

Web Resource is one of the most powerful and versatile extension mechanism in Microsoft Dynamics CRM. It supplies an open canvas to draw custom UI, business logic and whole applications within entity forms, dashboards and stand alone pages.
Coupled with the plethora of  free JavaScript libraries out there, you can easily provide your users with advanced solutions that work with Microsoft Dynamics CRM Data. In that sense, Web Resource can implement a custom client which can also be embedded into MSCRM elements.

One concern regarding the investment in Web Resource development is the loss of dynamic customization capabilities, which is MSCRM most prominent feature. Indeed, there is a price to pay when stepping outside Microsoft Dynamics CRM native clients.
The Customization Aware Web Resource approach can somewhat compensate as it suggests that whenever possible, attributes of elements within a Web Resource (mostly HTML & JavaScript) will be coupled with relevant customization features. So customizing entity field attributes like display name, description, requirement level, OptionsSet options etc. will be automatically reflected in your Customization Aware Web Resource.

Technically, this can be achieved by using the metadata querying capabilities of the OrganizationService or the Web API services.
Off course, this approach is relevant to any custom client, not just Web Resources.

One issue to consider when using the Customization Aware Web Resource approach is performance. While the OrganizationService.svc allows querying multiple entities & attributes with one query, the Web API service can only query one attribute at a time, so multiple queries may be required. Metadata queries are considered expensive, so if you plan to rely heavily on this approach, you should cache metadata queries results along with some cache invalidation mechanism.

In the following post, I’ll demonstrate a possible implementation of this approach. Stay tuned

Web API: Executing Custom Action via JavaScript

The Custom Action is an important tool in Microsoft Dynamics CRM architect belt. Here are some of the Custom Action key features:

  1. It can be called from both client & server side, enabling the SPoI approach (Implement once, consume anywhere)
  2. Supply a flexible, declarative business logic definition mechanism which can be called from other Processes as well as from custom code (unlike Plug-in)
  3. Can be extended with Custom Workflow Activities
  4. Can receive input parameters and return output parameters in a straight forward manner, similar to an Organization level Web Service

Why would you want to execute a Custom Action (which is a server side mechanism) via JavaScript? Here are some excellent reasons:

  • Provide an improved UX, as Custom Action can be executed a-synchronously from entity forms, web resources and Ribbon/Command Bar controls without blocking the user UI
  • You can bind server side logic to client side events, e.g. calling a Custom Action from an onChange or onSave event handlers
  • Implement a chunky rather than chatty communication with the server, as Custom Action usually wraps multiple operations which otherwise require multiple API commands

You can execute a Custom Action via JavaScript using raw SOAP (not recommended) or better yet, using the Sdk.Soap.js library (still SOAP, but nicely wrapped).
With Microsoft Dynamics CRM 2016 Web API you can now execute a Custom Action in the most simple manner, which is demonstrated in the rest of this post.

You can download an unmanaged Solution containing the sample Action and JavaScript code. This solution is for demonstration purposes only, please do not install on production or other critical environments.

  1. Define and activate a Custom Action in MSCRM 2016 Organization

    My sample Action receives few parameters, creates a Lead record and returns the new record URL.
    Note that this Action is defined for a global context. Also note the Action’s unique name and parameters names which are used in the following code.

    Define Custom Action

  2. Write JavaScript code to consume your Action

    The handleWebLead function defines the dyn_HandleWebLead Action name and parameters.
    It than calls the generic activateCustomAction function to execute the Action and return the output result.

    Define calling function
     
    The Action is executed using XMLHttpRequest which is defined to execute synchronously.

    Define Action executing function

Visible By Default – What Is It Good For?

image

Short answer: improving form performance & user experience, that’s what.

Long answer:

Since version 2011, major entity form elements (Control, Section, Tab) have the Visibility attribute added. This attribute, which is checked by default, determines if the form element will be visible to the user when the entity form loads.

Why would you want to render some elements invisible when the form loads? Here are some common reasons:

  1. Conditional logic: The form has some business logic related process which requires displaying some elements according to the user actions, e.g, hide Government Id attribute if the user selected Organization as Customer Type.
  2. Hiding built in required controls which can not be removed from the form and are meaningless to the end user.
  3. Hiding controls that are used to support the form business logic and has no meaning or use to the end user.

One uncommon reason to use the Visibility attribute is to improve form performance. I would like to elaborate on this, since I noticed many Microsoft Dynamics CRM developers are not aware of the impact which JavaScript code has on form performance which In most cases directly affect UX.

How can the Visibility attribute improve form performance and UX?

Business logic often requires script to hide/display form elements according the user actions. When the form loads, only a subset of controls should be visible to the user.
In many cases, the JavaScript code/form business rules which is triggered by the form onLoad event, literally hides all the form elements (some times, each individual control) and then render the required elements visible again.
Not only this approach waste client resources (inefficiently hiding controls which were just ‘painted’) but it also provides bad UX as it slows the form load time. With low resources machines, the user can also see the controls flick on the form before they are hidden by the JavaScript code.

The right approach in this scenario would be to uncheck the ‘Visible by default’ attribute for the elements which are not required to display on form load  (preferring tabs over sections, sections over controls) and writing JavaScript code to render elements visible when required.

This approach will improve form performance & UX because of the following reasons:

  1. Less form controls to render: the form will load faster because it has less controls to render. In control heavy forms/slow machines, this is substantial.
  2. Less code lines to execute: since custom hiding related code/Business Rules logic is removed, the onLoad event will complete and turn control to the user faster. You can write less code by hiding/displaying containers such as Tabs and Section rather than relating to each individual control. Again, think control heavy forms.
  3. Reduce visual load: no element flickering on the form will provide better UX.

User experience is critical to the application acceptance and over whole rating by users. Developers sometime miss these problems because the from loads fast enough on their dev machine.
For users who open record forms many times a day, even 2 seconds less form loading time can make a major difference.