Customer Insight Journeys Real Time Dynamic Forms Loader

Customer Insight Journeys Real Time Dynamic Forms Loader

In a previous post I blogged about how to break down the Form script that was exported from CI-J (Real Time). As some customers asked me about making this into a script that was the same and was dynamic based on query string parameters (parameters in the URL), I worked a bit on that and thought I’d share it here;

<div id="formdiv">

function getQueryParam(name) {
         const queryString =;
         const urlParams = new URLSearchParams(queryString);
         const queryparam = urlParams.get(name);
         return queryparam;

        const formobj = document.querySelector('#formdiv');
        const formid = getQueryParam('id');
        const formapiurl = '' + getQueryParam("orgid") + '/landingpageforms'; 
        const formcachedurl = '' + getQueryParam("orgid") + '/digitalassets/forms/' + formid;

        formobj.setAttribute('data-form-id', formid);
        formobj.setAttribute('data-form-api-url', formapiurl);
        formobj.setAttribute('data-cached-form-url', formcachedurl);
    <script src=''></script>

A few things that can be mentioned. This script expects that there will be two query string parameters:
id – the id of the form. Click on the form and copy it from the URL after the “id=”
orgid = the orgid which you can find in the PPAC or in the export of the script as I described in the previous article. If it is placed on the url: then an example of the url would be:

Finally some organizations also have problems with loading a script from external sources. I will look at that too. Mainly there are two option. Copy-paste the entire script inline into this script or copy the script file to an “internal” or recognized store with a public URL and change the src-attribute. If you move this away from referencing Microsoft, I would recommend checking their website on a regular basis to make sure it hasn’t changed.

I hope this helps out!

Breaking down form script in Customer Insight Journeys

Breaking down form script in Customer Insight Journeys

When creating a form in Customer Insight Journeys (real time) one option is to embedd it in an existing page. A customer asked me if it was possible to get this script from the API some how. Turns out that you don’t have to. It has a logical build-up and you can generate it yourself with a script.

First of all, let’s have a look at the generated script;

        data-cached-form-url='' >
<script src = '' ></script>

I have highlighted two different guids (I have changed them so they are not the actual guids).

The first one; 2e2b50a9-0000-0000-9079-0022489ca998 this is the Form id. It is the exact Id of the form that you have created. Easy to confirm by checking the id-parameter in the querystring for the form. This can easily be queried from the WebAPI from the table msdynmkt_marketingform.

Second guid; 4e5c8ea2-0000-0000-ac66-a30471bdf4fa is the instance id of the dataverse instance. This can be found in the Power Platform Admin Center under “Organization Id”. This is hence the same for all forms that are from the same instance.

The rest of the script is the same. Hence you can generate this quite simply with a script if you have these two values. I don’t know if the library referenced might risk being changed during updates or similar. Hence I would recommend using it with the same reference as seen above, but it might also be possible to download it and host it yourself. This is not something I have tried.

A colleague of mine, Thomas Passad, also mentioned that some CMS:s, like Optimizly, cannot handle the script being reference directly and that it had to be placed in some general footer or similar.

With this knowledge I think it is possible for you to handle this script in a more dynamic fashion but make sure to check that it hasn’t changed every month or so, as it might cause issues if there is a change and you havn’t taken that into consideration.

Resco javascript development – be careful of variable names

We are all new to stuff sometimes and I am currently quite new to Resco.NET and the JavaScript API it has. There is quite a lot of information and examples on Resco’s site regarding this but you know how it is when you get going, you’re always looking for something that just isn’t there. Today I thought I was missing some vital part of how to parse the data, turned out I was addressing the fields incorrectly, so I thought I’d share it with you in case you ever got into the same spot.

Well, my current Customer likes the Resco mobile client a lot. They like the ability it has for configuration and the fact that it is so configurable and even has API:s allowing us to make custom webpages for them that they can take offline, as Resco does support full offline.

Back to my problem, I was trying to show some data from the account entity on the html-page and as I had previously tried this, I had no problems with the name field. However, when I tried retrieving a field that we had created, let’s call it “Type” I looked in the list of fields in Woodford as I thought this was their view of the fields and hence how I was to address it. The name it showed was the weird REST-endpoint name with Camel-case “crmk_Type“, but I didn’t Think to much about this and used it in my code. The result was that I just got “undefined” as the returned value from the Resco JavaScript Bridge. It took me quite some time and a very helpful support guy at Resco before I opened the form editor in Resco and noticed that the field name set there was the normal name, used in the database/soap webservice, “crmk_type“. Upon noticing this, I tried the lowercase version and it worked like a charm.

My conclusion is hence that the field names that are to be used in the Resco JavaScript bridge are the lowercase field names, not the Camel case versions, despite the fact that these are the once that you see in the Field list in Woodford. Also, make sure the field that you are addressing has been included in the the field list. This might be changed in the future. If so, I hope to be able to write an update on the subject.

Here is a link to the Support page at Resco.NET where you can download the bridge file and also at the far bottom, go to the reference pages for the Bridge.

Gustaf Westerlund
MVP, CEO and owner at CRM-konsulterna AB

Resco javascript Fetch all account example

I have recently been working on a Proof-of-concept for a customer with the mobile platform. It is the first time I have been working deeply with it and I really like it. The woodford customization tool is very powerful and easy to use. It also allows customizers to add custom components such as offline html and js-components that can be used to extend the built in functionality where the standard forms do not meet the customer’s requirements.

In this case my customer wanted me to prove that it was possible to create an overview screen for an account showing lots of related information on a single screen. As Resco does not intrinsically support subgrids, like Microsoft Dynamics CRM does, you have to create this with a custom html which loads this data from the offline Resco storage. In theory this shouldn’t be too hard. It proved to be a bit more of a challenge, especially since the Resco Woodford manual contained some errors why I thought it might be a good idea to publish an example of how a complete code example of how to fetch a list of accounts wrapped in a working html-page that can just be copy-pasted into a file and tested out. This was one of the issues I had as just getting a simple base-line to work from was quite a lot of work.

So, without any more bells and whistles, here is the code:

<!DOCTYPE html>

    <title>Account List</title>
<script type=”text/javascript” src=”JSBridge.js”></script>
<script type=”text/javascript”>

function writeError(text) {
var error = document.getElementById(“errortext”);
error.innerHTML = error.innerHTML +
+ text;

function callbackAccountsLoaded(res)
    writeError(“In callbackAccountsLoaded”)
function callbackAccountsFailure(res)

function onAccountLoad() {

    try {

        var account = new MobileCRM.FetchXml.Entity(“account”);
        account.filter = new MobileCRM.FetchXml.Filter();
        account.filter.where(“statuscode”, “eq”, 1); // which have “Active” status

        var fetch = newMobileCRM.FetchXml.Fetch(account);

        fetch.execute(“Array”, function (res) { callbackAccountsLoaded(res); }, function (err) { callbackAccountsFailure(err); }, null);
    catch (e)
        errortext(“Error: “ + e.message);
<body onload=”onAccountLoad();“>
<div style=”height:300px; id=”errortext”></div>

Some of the important points here are:

1.      account.filter.where needs to be used instead of using account.where directly as indicated in the example in the Woodford manual. It also needs to be instantiated with the “MobileCRM.FetchXml.Filter();”

2.      The fetch.execute is referencing two callback functions, one for success and one for failure. Make sure these references exist and have the correct number of arguments.

3.      I have not found any decent way of debugging javascripts within Resco. I would be more than happy to be corrected here. Using alerts will not work on all platforms (Resco indicates alerts do not work on Windows 8 RT for instance). Hence I have created the errortext-method which outputs text in a log-file manner to a div at the end. Make sure that the height is enough.

4.      To be able to load information on the currently edited object, if the iFrame is shown in the context of an account for instance, then MobileCRM.UI.EntityForm.requestObject() has to be used.

5.      The first parameter of fetch.execute indicates how the result is to be formatted. In this example I have chosen “Array”, but there are other choices like “JSON” and “XML” as well. Please refer to the Woodford manual for more information on this.

6.      Do try to use try-catch around a lot of this as any errors will otherwise just not show when run. If there is an error, you can display the message and at least get an idea of what was wrong.

7.      When developing, I like to use Windows 8/8.1 and maybe a CRM Online/IFD environment as that will allow me to install the Windows 8 version of the Resco CRM to try it out. The different platform clients for Resco are 95% identical, some UI differences and I have seen some other differences as well, but in general, it will speed up development a lot and you will only have to do the final development tests on the iPad/Android device.

If I get a lot of interest in this, I will publish more on this subject. As mentioned earlier, I havn’t found that much community content on Resco, the mobile client I currently feel is the premier choice, as the Microsoft Mobile client is a bit simpler in its design, features and also customizabilities.

Gustaf Westerlund
MVP, CEO and owner at CRM-konsulterna AB

Errors when programmatically attaching events in forms

Today I had a very weird error. I had two datetime fields on a form, one on the first tab and one one the second. Let’s call them date1 and date2 to make it easier.

I attached an event in the onload by using

crmForm.all.date1.attachEvent(“onchange”, myFunc1);

and for the date2 field:

crmForm.all.date2.attachEvent(“onchange”, myFunc2);

The weird part was that if I changed date1 first and then date2, myFunc2 didn’t fire. But if I first changed date2 and then date1, both fired as they should.

So I tried just adding an alert instead using the normal onchange method via the form editor in CRM and that triggered every time, just as it should, so something is different.

The simple solution seemed to be to move date2 from the second tab to the first. That got everything working just as it should.

I havn’t tried it but I think that one could also write a method that confirms all the event attachments and then calling this at the end of every onchange triggering function and perhaps some extra time when the tabs are changed to make sure the events are bound correctly.

I have checked the documentation in CRM for if this kind of runtime event attachment might not be supported but my interpretation of the text is that is should be all right according to it. The closest paragraph in the unsupported customization section is the following:

“The use of custom HttpModules to inject HTML/DHTML into the Microsoft Dynamics CRM Forms. “

As I wrote, my interpretation is that attaching events (not even overwriting the onchange), should be ok according to this since we arn’t injecting anything, just adding an event listener. Hence I feel that this must be interpreted as a bugg in CRM.

Gustaf Westerlund
Microsoft Dynamics CRM Architect