Monthly Archives: September 2017

Using Microsoft Flow to capture web form submissions in Dynamics

It’s incredible how much we can do today using all the cloud tools compared to what we would be able to do just a few year ago.

Imagine you had a web form on your web site, and, possibly, you were not that much interested in setting up a customer portal.. but you would still want to forward web form submissions directly to Dynamics.

If it were 3-4 years ago, you would likely have to hire a developer to implement the integration and all that. Today.. You don’t really need a developer anymore. At least you don’t need somebody who can develop for Dynamics. Anyone having a bit of web development skills should be able to add that kind of functionality to any web site.

Because, you see, Microsoft Flow has come a long way, so we can use it to connect web forms to Dynamics in the following manner:


I’ll show you how to do it, but you might also want to read the following article at some point:

It was posted by Irina Gorbach almost a year ago, and, essentially, it has all the details required to implement the process outlined on the diagram above.

Let’s do it step by step:

1. I will need a flow

In that flow, we will have only two components: there will be a Request trigger and a “Create new record” action (Dynamics 365 action).

To set up the request, I have used the following JSON Schema:

  “$schema”: “”,
  “type”: “object”,
  “properties”: {
    “firstName”: {
      “type”: “string”
    “lastName”: {
      “type”: “string”
    “email”: {
      “type”: “string”
    “message”: {
      “type”: “string”
  “required”: [

This will allow me to pass firstName, lastName, email, and message parameters to the request.

The second step in my flow will create a record in Dynamics. It’ll be a new lead, and I’ve mapped all 4 parameters of the request to the lead fields:


Once the flow has been created, I just need to grab the url of the request since that’s what I’ll need to use for the javascript below:


2. I will need a web page and a javascript

Here is the HTML will look like:

First Name:
<input style=”width: 300px;” id=”firstName” type=”text” />
Last Name:
<input style=”width: 300px;” id=”lastName” type=”text” />
<input style=”width: 300px;” id=”email” type=”text” />
<textarea style=”height: 100px; width: 300px;” id=”message”></textarea>

<input id=”submitButton” type=”button” value=”Submit” />

<script>window.onload = function () {
    document.getElementById(“submitButton”).onclick = submitForm;
function submitForm()
   var xmlhttp = new XMLHttpRequest();   // new HttpRequest instance“POST”, “
   xmlhttp.setRequestHeader(“Content-Type”, “application/json;charset=UTF-8”);
         firstName: document.getElementById(“firstName”).value,
         lastName: document.getElementById(“lastName”).value,
         email: document.getElementById(“email”).value,
         message: document.getElementById(“message”).value
  alert(“Thank you!”);

First, there is some HTML there to display all the input fields. And, then, there is a javascript that will do a couple of things:

– It will configure “onclick” for the button

– It will actually implement the onclick

You may ask why it’s done like that, why not to use JQuery etc.. It’s just because I was testing it in WordPress, and I did not really want to do anything I did not have to. But you can easily re-write this javascript for JQuery if you want to.

All that script has to do in the submitForm function is to create an XMLHttpRequest object and use it to post json-serialized form fields to the flow Request url. The flow will take care of the rest.

Let’s do a quick test?

– Filling in the form:


Getting a new lead in Dynamics


That was not that difficult at all, so you might, actually, consider going with the Flow the next time you need to do this kind of integration.

Team Work: how does this solution work?

This is going to be a follow up for the original post, so, if you have not read it, you might want to do it first:

Team Work: Is somebody else working with the same record?

In this post, I wanted to explain how that solution actually works since, it seems, that’s what was missing there.

Basically, the idea is that there is a special “Action Tracker” entity in that solution where record actions can be reported:


With that entity in place all that’s required is a bit of development to make the notifications work.

1. We need to add a javascript web resource to all the forms that we want to enable notifications for. Here is what it’ll be doing:


And that’s “Action Tracking” web resource in the Team Work solution.

It’s a “smart” web resource that does not require an “onload” event handler to be configured. It’ll just wait till Xrm has been initialized, and, once it’s there, it’ll start doing what it is supposed to be doing.

When verifying existing action trackers, it will check for all action tracker for the current record that have Action set to “Open”, and that were created by other users.

If there are any, it will display a notification.

On the other hand, it will also be creating new action trackers every 60 seconds just to let others know that this particular record has been opened by the current user.

2.  We need to implement some cleanup process so that those action trackers that are no longer needed do not get stuck there forever

That’s what “Team Work: Delete (Open) Action Tracker” workflow is for:


It’ll start on create of an action tracker and will set “delete” attribute of that action tracker to “yes” in 2 minutes:


3. And, finally, we need a plugin to actually delete the action tracker when its “delete” attribute has been set to “yes”

That’s what DeleteRecordPlugin is for:


As for #3, it could be implemented as a custom workflow activity as well. However, I think there are, already, lots of workflow activities in Dynamics.. the way I see it, there is no real need to pollute workflow designer with yet another one.

Either way, feel free to download the source codes etc directly from GitHub. If I missed anything above, you’ll find all the details there:

Exporting a solution–getting Invalid Business Process error


I was trying to export a solution earlier today, and, somehow, I was getting an error message:

Business Process Error
Invalid business process


The technical details were empty.. Just like this:


What was interesting is that I had exported a few other solutions just before this one, so, apparently, there was something wrong with this solution in particular. There were only two business process flows in the solution:


Removing that out of the box Opportunity Sales Process did not really help, so I knew there was something wrong with the “test bpf”.

You know what it turned out to be?

If you add a new business process to the solution and save it (without really defining any stages/steps..  just leave what’s there by default), you will get that error message when you try exporting your solution. 

Quite frankly, you might never run into that error.. Why would you export a draft of a business process flow, after all? But, if you do get that error message, this might save you some time.

Happy 365-ing!

Team Work: Is somebody else working with the same record?


What if your users wanted to know if somebody else on their team is looking at the same records? In other words, what if they wanted to see this kind of notifications in Dynamics?


I just created a solution which you can download from GitHub:

Or, if you just wanted to get a Dynamics solution file, you can download just the solution file:

One you import it to Dynamics, you’ll need to do a bit of set up:

1. Assign “Action Tracking” role to all Dynamics users. That role will grant permissions required for this solution to work.

2. Add a web resource to all entity forms which you want to enable for this kind of tracking


Just add the web resource – no need to configure onload etc.

3. Save and publish those changes

And that’s it.. Now your users will be notified if somebody else opens the same records. Although, those notifications won’t show up immediately – it may take about a minute,  so the notification interval may have to be fine-tuned.. but I’ll talk about the implementation details in a different post (which you can find here:

Happy 365-ing!

Supported or not? Maybe it does not matter

Just came across an interesting post in the Dynamics Team blog:

Set default Business Process on a form while creating new record

It is interesting in two different ways. First, it is offering a nice example of how to implement a useful feature.  When there are multiple business processes per entity, we can order those processes using the configuration-only approach, but that’s just about as much as we can do.

If we wanted to select default business process based on some conditions, we would have to start customizing (aka doing scripts/plugins development), and that’s where a code samples like that one in the post above can be very useful.

However, this is where it becomes interesting in yet another way.

1. How do we normally check if we are on the “Create” form or on some other form?

We use Xrm.Page.ui.getFormType, right?

Here is how it’s done in that code sample above, though:

( == null || == ‘undefined’ || == ”)

Remember this is a Dynamics Team blog, so.. it’s interesting they are not using getFormType there.

2. What parameters can we pass to the form? More specifically, can we use process parameter?

parameters[“process”] = procesGuid;


According to this:

We can pass Form Id and Default fields ids.. Would it be too much to say that script is using.. shhh.. unsupported parameter?

It does not make that code sample less useful at all, but it does bring up the question of whether it’s so important to use supported customizations only(although, there are, probably, different degrees of “unsupported”) when, it seems, even the Dynamics Team itself is suggesting some customizations which are not, necessarily, fully supported.

I don’t really have the answer..

If you are more on the development side, then you probably don’t care that much since, after all, if this saves you a few days of work and you know how to maintain it.. then why not?

If you are more on the project management and/or project maintenance side, you may want to make sure your Dynamics implementation is not using some tricky/unique/unusual customizations which will be difficult to maintain and/or to even recognize.

Apparently, it depends on how you are looking at it. But what do you think?