Leveraging Microsoft Flow to be your API Engine – Low Code Approach

Recently I’ve been experimenting with Microsoft Flow and its counterpart, Logic Apps. A thing that I noticed could become a game changer in designing a business solution these days is that Microsoft Flow can be turned into an API engine. In my example, I’m going to create a very simple API to send a message to my Skype for Business and reply back with the response whether the API call is successful or not.

The first step is by registering the HTTP Request trigger in the Flow step:


As any typical API, you will need to specify the data payload. To generate the payload schema, we can use the “Use sample payload to generate schema”. I’m going to use a simple payload to send the message:

      “message”:”payload for skype”
Once generated, this will create the schema for you
To ensure that the payload schema is validated on the HTTP request by clicking the Settings option:
And turn the Schema Validation to On
The next step is to register the action that you would like to perform (you could be creative here with the available connectors for Microsoft Flow or you can come up with your custom connector).
In my sample, I’m going to add the Skype for Business action: Send Instant Message
As any typical API, we will need to provide the response appropriately. In this example, I’ll just implement the success response. Exception handling will be discussed on a separate blog post.
Once finished, save the flow and the HTTP Request step will generate the API endpoint:
To test the endpoint, you could simply use Postman (or any tools to stimulate HTTP request) to trigger it:
And here’s the result:


To create a low-code API is now become very simple with Microsoft Flow. With the available connectors and actions, workflow-based API can be achieved in configurations!

Dynamics CRM 2013 – New Features Limitations

Dynamics CRM 2013 new features: Business Process, Business Rule and Synchronous Workflow are a major leap from CRM 2011. These nifty features added a lot of benefits to the selection customisation tool. For example, by using Business Rule, we could eliminate some javascript form scripting that might require more time to test. And Synchronous Workflow might eliminate plug-in development that sometimes quite tricky to test, especially on Online deployment.

In spite of the benefits that we could utilise from these new features, there are some limitations that we might need to aware of, especially in designing the best solution in terms of maintainability, performance and the time effort that need to be spent.

Business Process
In designing business process there are maximum number of processes, stages, and steps:

  • The maximum number of activated business process flows per entity is 10.
  • The maximum number of stages in each process is 30.
  • The maximum number of steps in each stage is 30.
  • The maximum number of entities that can participate in the process flow is 5.

Synchronous Workflow
With Synchronous Workflow, user could see the results by the time the record is saved (in CRM 2013 form, the changes that made are saved automatically every more or less 30 seconds interval or by clicking the TINY save button at the bottom right of the form), compared to javascript, where user could see the changes straight away.

Planning synchronous workflow might be similar to planning synchronous plugin, try as much as possible eliminate the long-waiting process to be registered as synchronous one for better user experience.

Business Rule
This is one of the killer features of the new Dynamics CRM 2013, but there are some limitations. And for some occasion, it will determine our conclusion whether we should go with javascript/plugin/workflow/business rule.

With current release, as far as my trial-and-error experiment with business process, we could only have one condition and one action. So it is like a single if statement:

If [this condition]
Then do [this action]

Meanwhile, if-else or switch-case scenario is not available

If [condition is A]
Do [action A]
Else if [condition is B]
Do [action B]
Else if [condition C]
Do [action C]
Do [default action]

To achieve this, we need separate business rules and might want to check whether one rule is unique to the other rules, which is quite messy for a solution.

If [condition is A] and [not condition B] and [not condition C]
Do [action A]
And so on…

Business Rules are Entity-Bound
The fields that can be used to build the business rule are only available from the entity that the business rule is attached to. So there are limitations when we need to access fields/condition from related entities (child/parent entity). To achieve this, we should choose either workflow/plugin/javascript path.

So far these are my findings on the limitation of the new features in Dynamics CRM 2013. In future post, I might add any additional limitations Dynamics CRM 2013 or Microsoft might release updates on these limitations to make Dynamics CRM 2013 as the best platform for xRM implementation.