Admin

In CRM 2016, when turbo forms are enabled, pretty much any unsupported code will break. Usually it’s easy enough to add a ‘parent.’ To the front of any unsupported code, however if you’re using the code from my blog post on how to do this in CRM 2013, there’s a few tricky things that need to be updated as well.

I’m not going to go into detail about how the code works, instead I’m just showing what the updated code should be. If you want the extra details check out the previous blog posts on how to do this for CRM 2013 and CRM 2011.

To get this working in CRM 2016 with Turbo Forms, you’ll need to append all the unsupported references with ‘parent.’. Also, you should change the ‘var parent’ to something else like ‘var parentObj’ so it doesn’t overwrite the DOM parent.

To make this easier, I’ve declared a new crmWindow variable, which makes use of the internal method of checking if turbo forms is enabled, so this code will work in CRM 2016 whether turbo forms is enabled or not. This variable also replaces the ‘context’ variable in the old code, which was just a reference to ‘this’ (the current window).

The full updated code is below, with changes to the CRM 2013 code being highlighted:

Rate this:

Every time I have to do something with activities in CRM it ends up taking way longer than expected. Unlike most entities in CRM, activities have a lot of unusual relationships and field types, not to mention all the behind the scenes processes which tend to not like when you introduce your own custom logic.

In this blog post I want to simply look at party list fields, and how to read and update the field values.

An activity partylist field is like the To, CC, BCC fields on an email – they can contain multiple entity references, and they can also contain different entity types (contact, user etc). When we for example do a retrieve on the email entity using the SDK, the ‘to’ field is of type EntityCollection.

If we break this down, each Entity in the collection is an ‘activityparty’. The Activity Party entity is the intercept entity for all the activity party list fields. Activity parties are not only used for the party list fields however, they’re also used for the regarding and appointment organizer etc.

So what fields do we get from each of the activity party Entity objects?

If we break it down, it has 3 main fields. The partyid, which is the actual EntityReference to the contact, user, account etc which is being referenced. The addressused, which is only really used when emails or appointments are tracked from outlook; this is the actual email address of the recipient that CRM used to match it to a record. Finally there is a field called ispartydeleted, which simply tells us if the record behind the activity party has been deleted; since CRM does not delete the activity party, nor does it clear the partyid, this is the only way of knowing that the record actually exists (without trying to retrieve it or something).

When you’re creating an activity party, you need to set the partyid and/or the addressused. You must set at least one, and they cannot be null – so make sure not to add it to the property bag if there’s no value. CRM will throw an error if neither attribute is set, or if you explicitly set one of the attributes to null.

If you specify an addressused and not a partyid, the activity party will be ‘unresolved’ on the activity. It will display as just the email address, with a red font.

You don’t need to do an SDK Create or Update request on activity parties, just update the EntityCollection and add it back into the parent activity ‘to’ or ‘cc’ field etc and then update/create the activity – CRM will take care of creating or updating the parties.

If you’re copying activity parties from one activity to another, or from one partylist field to another, make sure to remove the activitypartyid from the Entity objects, as these are unique for each party. Simply leave this field out of the attributes list so that CRM will create a new activity party.

If you want to delete an activity party, simply remove it from the EntityCollection. CRM will take care of deleting the activity party record behind the scenes. This example removes the unresolved and deleted parties from the ‘to’ field.

Rate this:

CRM by default doesn’t allow us to create our own custom fields using rich text or HTML, similar to the email Description out of the box. However, if we’re building forms that push data to a website dynamically, we may need the ability to build some HTML in CRM. In the past there’s been a few solutions available to do this in CRM. Some are more unsupported than others (e.g. hacking into a field on the form and converting it into a rich text editor).

I have made the solution dynamic enough so that it can be dropped into any form by simply embedding the html editor web resource into the form, and passing in the field name to store the HTML data.

You can also set the Formatting to display the number of rows required, and to disable the iframe scrolling and border for a nicer look and feel. The HTML Editor will automatically expand to fill the space available inside the iframe, however big you choose to make it.

You can also pass a default value into the HTML editor, which will be applied when there is no existing value (e.g. for new records). This can be useful when you want to ‘guide’ users into entering the HTML in a specific format, rather than just letting them loose.

The default value needs to be encoded, and then included in the custom parameters of the web resource. You can get the encoded URL string from the following webpage by pasting in some HTML and then clicking ‘Encode’: http://meyerweb.com/eric/tools/dencoder. Copy the encoded string and add it to the web resource parameters after the field value, e.g. field=new_html&defaultValue=%3Cb%3EHello%3C%2Fb%3E

The defaultValue parameter is optional, and if not specified, the HTML editor will simply display nothing initially.

Next we can preview our form and see that the html editor just works. We can see the default value being applied, including the ‘bold’ styling, and our basic editing tools are available.

The data from the HTML editor will be saved to the ‘HTML’ field every time you click out of the iframe. This means you don’t need to manually ‘save’ the HTML, it will just automatically keep up to date by itself. After we’ve saved the form, we can reload the page and the HTML editor will load up the HTML from our field automatically.

We can now hide that HTML field (as long as it remains on the form), and the HTML editor will continue to work and look pretty.

The buttons/editing tools available in this solution are based on the ‘Basic’ package provided by CKEditor. This is because the basic package seemed to meet our particular needs as we didn’t require a full blown HTML editor, just some basic rich text editing tools. This also means the entire solution is only 17 web resources.

If however you do require any additional editing tools, you can check out the CKEditor download page and create yourself a custom download package, and then just be sure to upload the missing web resources using the same publisher prefix, and same file names, then update the config.js file to load those plugins as well.

Note that this solution works in CRM 2013 as well as CRM 2015, and works on any entities. You can also add the HTML editor to the same form multiple times, each referencing different fields.

Rate this:

A common requirement is to open a dialog process from JavaScript on click of a command bar button etc. This is quite easy to do, simply using window.open and passing in the right parameters to get the dialog working with the right record.

The problem is that this doesn’t allow us to run code when the dialog closes. We could use modal dialogs, but these are not supported in Chrome. Instead what I’ve done is created a manageable function for running a dialog, which allows us to run code when the dialog is closed.

It works by popping the dialog in a CRM light-box, which makes it look natural and seamless. When the dialog is closed, a callback function which we specify can be executed.

If the code runs inside outlook, where CRM light-boxes are not supported, a modal dialog is instead used, which still allows us to run our callback function when the dialog closes.

Call Dialog

Opens the specified dialog for a particular record in a CRM light-box, or Modal Dialog if run from Outlook. Once the dialog is closed, a custom callback function can be executed, e.g. to refresh the form with new data set by the dialog.

Rate this:

In my previous blog post I introduced a new JavaScript library for calling processes, and I showed the function for calling a workflow. In this blog post I’m going to look at the function for calling an action.

Actions can be very useful when coupled with JavaScript, as it means we can execute complex server side logic, access fields from related records, or execute C# code using custom workflow activities right from within our JavaScript. The problem is, similar to calling workflows, we need to create a massive ugly SOAP request every time we want to call an action. With actions however, we also need to think about what parameters we’re passing to the action, and what output parameters we’re getting back.

For these reasons, it’s much easier to manage this in a library which we can easily call, and don’t have to worry about remembering the correct format for creating the requests.

We can see the action here, which takes 1 string input parameter (plus the Target account reference, since this action isn’t global), and then returns 1 string output parameter. The output parameter includes the input parameter to prove that the action is receiving the input parameters correctly.

When the action is called, we can see the success callback function firing and alerting the output parameter, including the input parameter we passed to the action.

Rate this:

In a recent project I worked on, we needed to display a hyperlink in the form notification so that a user could click on it to open up an external webpage with parameters from the form. This proved to be a lot more difficult than initially anticipated, as CRM does not render any HTML tags that you pass into its setFormNotification function. This meant we needed some way of editing the HTML of the notification, which of course is unsupported. We also found that CRM re-renders the form notifications without warning when certain things happen, such as when the form is saved, or when additional notifications are added/removed. This meant any custom HTML was wiped randomly without any way to control it.

Because of these limitations, I decided to just create my own notification bar, using all the existing features available to the Xrm.Page.ui.setFormNotification SDK function, but also added a whole range of new features outlined below.

Features

Any existing code using Xrm.Page.ui.setFormNotification and Xrm.Page.ui.clearFormNotification can easily be updated to use Notify.add and Notify.remove without the need to modify any parameters, and without any noticeable differences

Allows you to add buttons and/or hyperlinks into the notification, with custom JavaScript triggered on click

Supports additional icons, including SUCCESS, QUESTION, and LOADING

Supports custom HTML tags to be used manually in the notification message for greater flexibility

Ability to manually close a notification using the ‘X’ on the right hand side

Has smooth slide in and out transitions when adding and removing notifications

Ability to specify a duration after which that particular notification will disappear

All parameters are technically optional. If there’s no icon specified the icon will be removed. If the unique ID is not specified, the ID will be null (and any new notifications with no ID will overwrite that one). The buttons are optional and will display after the message in the order they are added to the array. Duration is optional, and if not specified the notification will only disappear if the user manually dismisses it or if other code removes it.

Each button object in the array should have a ‘text’ to display on the button or hyperlink, a ‘callback’ function to call when the button or hyperlink is clicked, and optionally a ‘type’ of ‘link’ or ‘button’ (defaults to button if not specified)

Remove Notification

This function removes one or all notifications from the custom notification bar. If an ID of a notification is passed to this function, that notification will be removed. If no ID is passed to this function, all notifications will be removed.

Rate this:

In the past if you’ve needed to call a workflow from JavaScript, you need to build a massive XML SOAP request making sure to pass in the correct attributes and conditions to get the request working.

This is tedious and messy, especially when there are many places you need to do this in a solution. It’s also not good if something breaks in the future and you need to go back and fix up all instances of where the code is being used.

For these reasons, I’ve created a JavaScript library to simplify calling processes, and to make the code manageable going forward. But most of all, it’s so I don’t have to keep finding the correct way to build the SOAP requests!

This library includes functions for calling workflows, actions, and even popping dialogs. For this blog post, I’ll just look at calling workflows. I’ll cover calling actions and dialogs in other posts.