Why use Microsoft Flow?

Microsoft flow helps you to simplify your day to day repetitive tasks to flows, that can run or execute automatically without much manual intervention.

If you are a little familiar with Dynamics 365 processes or out of box workflows, where we usually configure actions for a repetitive task.

We will create a basic flow which will email new contacts created in Dynamics from the administrator confirming the contact has been created.

Step 1: Access Microsoft flow directly from this URL: https://flow.microsoft.com

Step 2: Or if you have an Office 365 subscription, you can directly access Power Automate or flow from the Office 365 App launcher.

access microsoft flow

Step 3: On the left hand of the screen we can navigate to “My flows” and select “New Flow” and from this dropdown menu we select “Automated cloud flow”.

Step 4: You will see a prompt window like below, we can set the flow name to test. From this window, we can search “dynamics” and select the following “flow trigger”“When a record is created”.

Step 5: Now we can select the entity’s from our Dynamics 365 which we would like to select to help automate our task. In the example below I have selected “People” and “Email Messages”. This is so when a new Person (People) is created we would like to send an email to the new contact confirming a Contact has been created. Once we have the correctly selected organisation and entity we can now click on the drop-down menu “Show advanced options”.

Step 6: Now we can select the sender of the email, which will be the First Name. This will include the name of the sender which the contact will see in the automated email that will be sent to them.

Step 7: Now we have to set the recipient of the Email. This will be email that is entered upon creation of the contact in Dynamics. It is set so every new entry in contacts will look for the email and send it to that address.

Step 8: Finally we can test our Flow by selecting test on the top right of the screen. Here we can select manual test and create our Contact in Dynamics 365. Once the contact is created with an Email we will see a Succeeded message on our test, and if expanded it should list the email entered when Contact is created.

Unit testing is important but… where do I start?

If you have attended the increasingly popular CRM Saturday conference, you probably gained some valuable insights around the key aspects of delivering successful CRM implementations, and how to overcome the main challenges one may face during the implementation.

If not, I encourage you to visit the web site, it has great speakers, great content, and lots of networking opportunities… not to mention is one of the few Dynamics events out there where attendance is 100% free.

Two of the sessions were around test automation and how to implement a true DevOps strategy for Dynamics CRM, two key areas and best practices to increase the overall quality and healthiness of your CRM implementation, which, in turn, would give you the following benefits:

  •     Turning your customers into even more happy customers  (external)
  •     Making your colleagues a bit less stressed because of regression / production bugs will be reduced (internal)

If you are still not convinced about why your team should unit test your code, here’s another blog post with the slides of the test automation presentation.

Once your team realises how important unit testing is, the next immediate question probably is:

  • “Ok, I have an implementation which has been running for years , and I have a bunch of existing code, not tested. At the same time, I have a limited set of resources and trying to unit test everything would be mad… where do I start?”

Ideally, one should achieve a code coverage above 90%, but if you have limited resources, my advice would be: the 80/20 rule.

Try to find the 20% of your code which represents at least the 80% of the total number of executions or executed time, just because if there is a bug in there, then it is likely to affect more users than a piece of code which is executed from time to time only (this might be actually more complex as maybe something than just runs from time to time may have a bigger impact based on a million different variables… but I hope you get the idea).

The next question might be…. how to measure it?

Well, it turns out, from a plugin / codeactivity perspective, you could extract that information from the System Jobs entity rather easily.

Every time a plugin / workflow is executed, a new entry in that table is created, with the Created On, Completed On, fields etc, so you could actually measure how much time a single workflow / plugin execution took. If you have an On-Premise installation, then that is just a SQL query with some groupings, if On-Line, then a data extract plus some Excel manipulation magic should be enough too or… make use of the great Organisation Insights feature in AppSource:

Are you unit testing your code? If so, how did you start unit testing legacy code? Did you use a different approach? We would love to know more about your own experiences.

Please leave a comment below.