Scheduling a record was not something achieved without some thought using workflows in Dynamics 365 CE. Mostly the ‘Bulk Delete’ trick was used where scheduled Bulk Delete of records (normally to remove legacy data) would act as the trigger for your custom workflow, effectively creating a scheduling system. Still, this doesn’t feel exactly clean and this functionality was not something that can be achieved logically from the workflow designer. This has since changed with Microsoft Flow.
Having a business system that gives actionable insights is important, allowing staff to be able to take information and turn it into useful knowledge relevant to their goals and mission within the business. This mission often involves interacting with customers. In an era of self-service, it’s not all the time the interactions are outbound, and customer interactions can come through via portals, landing pages, surveys and completing feedback forms in any length of time that is not guaranteed. The interactions can result in a, broadly categorised, positive, negative or indifferent experience for the customer. Given not everything is always going so positively with customers, wouldn’t it be amazing to know the general sentiment a customer has from the currently related interactions? This way, users can be alerted if a customer’s average sentiment changes to negative, or before you contact a customer you know if a recent interaction has made them less than impressed, giving you the opportunity to change their impression for the better.
A challenge in Microsoft Flow is to obtain specific data from a collection of objects (Like Dynamics 365 records) and use some data from those records within a single HTTP request. Why not make multiple HTTP requests within the ‘Apply Each’ loop I hear you ask? Well my friend, because there could be 100 records or more, that’s 100 hits to an endpoint which is really unnecessary, time-consuming and prone to error. Best Practice is, if the scenario allows it, to send as few requests as possible.
One of the weaknesses of traditional workflows within Dynamics 365 is their inability to natively iterate over child records. Great news! Microsoft Flow allows you to be able to iterate over child records and pass in query string parameters allowing you to limit the returned collection. It achieves this using OData syntax. Trust me though, even if you have never used OData syntax before, with a bit of trial and error you’ll pick it up in no time. Check out this post for a very quick start to iterating over child entities using Microsoft Flow.
Microsoft Forms is a service that allows for the creation of a basic form quickly and easily. Forms are no longer in preview just for educational organisations and are now in preview for everybody with a valid Office 365 Licence, which means we can now look at how this service can fit into the Dynamics 365 stack of technologies as it offers an alternative to other services such as those that are designed to create Landing Pages within Dynamics 365, or produce Surveys, essentially any sort of fast data collection or submitting you want the user to do. (There’s always positives and negatives of course which need to be weighed up with what you want out of the service you choose)