Often when people talk to me about my blog, it is my old posts on workflows which they remember with the greatest fondness. For example, I created an audit log for v4.0, auto-number solutions, and even a global search tool before it was a thing. Then dialogs came along (deprecated now so do not get too attached) and I showed how to create multi-select option sets, a timesheet entry system, and a text-based adventure game. I think Flow is going to be my new source of non-coding shenanigans.
My first piece of fun is linking Microsoft Flow with IFTTT to update a currency exchange rates in Dynamics 365.
What is IFTTT?
This is a bit of a circular definition because in my first part of introducing Microsoft Flow I likened Flow to IFTTT. Now I am doing the opposite. Essentially, both of them allow you to link different web services together to do interesting things. For example, my Flow introduction had an email create an attachment in the SharePoint document store of a Dynamics 365 Contact record.
The trick to linking IFTTT and Flow was finding a way for information to pass from one to the other. There are a number of services both attach to but, to keep things simple, I selected email.
Essentially, IFTTT reads the latest US to AUD exchange rate, puts this in an email and sends it to a predefined email address (in this case my Gmail address). Flow monitors my inbox and when it sees an email with the right format, it extracts the exchange rate and updates Dynamics 365.
The IFTTT Bit
Setting this up was very, very easy. I logged in to IFTTT with my Gmail email address, set the trigger to be ‘Stocks’, picking the exchange rate trigger option with the action being ‘Gmail’
Other than setting parameters, such as the currencies, the only other modification I had to do was to the ‘Ingredients’ (what we call Slugs in Dynamics 365) so that the subject line of the email was precisely formatted.
At midnight, IFTTT kicks in and sends an email to Gmail with the subject “FLOW <exchange rate>”. Here is what it looks like.
The Flow Bit
I have purposely kept things simple in Flow as I covered some of the finer points in my three-part introduction articles.
The trigger is ‘When a new email arrives’.
I have limited Flow to only worry about emails from firstname.lastname@example.org and I also have the option of filtering by Subject string if I need it, although I have managed that later on the Flow.
Next I set two variables. The first is “SUBJECT” which is a string and is set to equal the Subject of the email. The second is “RATE” which is a float and will become the new exchange rate.
Then I check a condition. In this case I am simply looking for any email whose Subject begins with ‘FLOW’. It is not hard to see we could have different Flows using different keywords to determine whether they should fire or not.
If the condition fails, nothing happens. If it succeeds, we set the RATE variable to the exchange rate in the email. For anyone who has used Excel formulae, this is not too difficult to master.
The Expression to use is:
This simply removes the “FLOW “ at the start of the email Subject and converts whatever is left to a value of type float.
Finally, we update the appropriate Currency record in Dynamics 365.
There are a couple of things to note here. Firstly, all the mandatory fields in CRM are mandatory here, even though we simply want to update one field. This means we need to type in values for Currency Name, Currency Precision, and Currency Symbol, and the Exchange Rate. Secondly, I have hard-coded the Guid (the Record Identifier) although this could be easily retrieved using the search trick from the third part of my Flow introduction.
The result is an exchange rate in Dynamics 365 which is updated every 24 hours at midnight.
Is Flow the Future of Development?
It is true that because we can do something does not mean we always should. Such is the case with Flow. Just because a citizen developer can develop some very interesting Flows, we still need appropriate governance and management and sometimes this will mean traditional development is the better option.
Taking the above as an example, if we implemented our IFTTT/Flow combo into a production system, we now need to maintain an IFTTT Applet, a Flow, an email address in Gmail and so on. We can imagine that doing this for a dozen such arrangements becomes unwieldy.
Using development, we can centralise the configuration in one text file (or custom entity record) and create a console app to retrieve the exchange rate. As an example, Matthew Foy walks us through how to do it here for an on-premise Dynamics CRM implementation.
Also, as with any developed functionality, security need to be considered. Could someone mess with my Dynamics 365 system by sending an email with a bogus exchange rate in it? Where is my data going and can it be intercepted? Again these issues may be easier to manage in a developed solution.
We have some amazing power in our hands with Flow and even more so when we combine it with IFTTT. The trick for many organisations will be finding the balance between the rapid development of functionality using tools such as the above, and ensuring the result is maintainable and secure. For me, I will continue to work with Flow, coming up with codeless solutions to common Dynamics 365 problems, and continue to blog about them to give people an idea of how far they can be taken.