I was working within CRM recently, attempting to configure some form level logic in order to display/hide fields, based on certain conditions on the form itself. I went into it rather gung-ho and immediately started writing the following JScript function:

function hideFormFields() 


    var myField = Xrm.Page.getAttribute("jg_myfield").getValue();

    if (myField = "Value1") {



    else if (myField = "Value2") {



I then suddenly thought “Hang on – can’t this be done via a Business Rule instead?”. For CRM Administrators who do not have any previous development skills, Business Rules were a godsend when Dynamics CRM 2013 was first released, having been continually improved since. They essentially enable you to implement conditional logic and actions on your entity forms, without the need of writing a single line of code. Business Rules are, in fact, a form of JScript, utilising many of the capabilities available as part of the XRM framework. As an excellent case in point, we can very easily replicate the above code into a Business Rule, like so:


There is an important lesson here, that anyone who works extensively within CRM needs to always remember; if it can be done out of the box within CRM, then why would you go to the trouble and effort to write a JScript function? Here are some reasons why CRM Developers should always think twice before typing away on that new form-level JScript function:

Business Rules actually do a lot more than you’d expect

This is something I am guilty of forgetting, and I’m having to train myself to consider this more carefully in future. In the above example, I made the immediate assumption that showing/hiding form fields on a conditional basis was not possible via a Business Rule – how very wrong I was! This seems to underline a general theme with how CRM customisers/developers approach Business Rules, assuming a glass half-empty approach. As of 2016 Update 1, as well as being able to modify a fields visibility, Business Rules can also support the following scenarios:

  • Show Error Message
  • Set Field Value – Fields can be set to match the value of another field, a specific value (including lookups), the result of a formula (Date/Number fields only) or be cleared of data.
  • Set Business Requirement.
  • Set Default Value – Fields can be set to match the value of another fields, a specific value (including lookups) or as the result of a formula (Date/Number fields only).
  • Lock or unlock field

What emerges, when combined with the conditional logic builder, is a means of utilising some of the most frequently used methods available to you via the SDK. And we can also hope and anticipate that as part of future releases of CRM, this list will be expanded on further.

Business Rules are supported, whereas your JScript may not be

To summarise another way, although you can do lots of things via Jscript within CRM, that doesn’t mean that you should. One thing I have observed with those who work with CRM, but have had more of a developer background, is that there is tendency to utilise methods/code which is not officially supported by Microsoft within CRM. Looking around the CRM community, and you often see that an unsupported solution is provided to a specific requirement, but often with no warning label attached to stress what it is doing. A good example of something which is unsupported is manipulating the Document Model Object (DOM) of the current page. Just because it works now doesn’t mean it will in the future, potentially causing major problems for your CRM deployment. If you are ever in doubt, be sure to review the supported extensions article on MSDN for CRM, and always think twice before you start using that nice bit of code you find on a Google search.

Your JScript may cause problems for end users

So your JScript is supported – great! But that doesn’t necessarily mean it’s going to work well from an end users perspective. If your JScript code, for example, does not provide a sufficient level of error handling, your end users could end up receiving error messages frequently. Or perhaps consider a scenario where your code is handling your errors well and outputting them correctly for potential debugging; this can lead to more lines of code that are unnecessary, and cause an impact when running the application on certain machines/browsers. With Business Rules, you don’t have to worry about addressing that careful balancing act between form loading times versus JScript library sizes. And, you can be assured that the CRM application as a whole will be able to handle your custom logic without affecting the performance of your deployment.

Jscript should have a time, place and bespoke requirement

What I mean by this is that JScript should only really begin to factor in when you are dealing with very specific, business requirements that the application “as-is” has no means of satisfying. An example of this is if you need to provide specific data validation to a field (such as a telephone number or bank sort code number). The only way this is ever going to be possible is via some kind of Regular Expression (RegEx) validation, which can only be performed via JScript. As one the key takeaways from this blog post, I would stress that you should always first attempt to build a Business Rule that is designed to meet the requirement that you are looking for, utilising other out of the box elements where appropriate (fields, workflows etc.). When it starts to become pretty obvious that a Business Rule is not going to cut it, then you can “give yourself permission” to start writing a JScript function 🙂

A “No Code First” approach should always prevail

I was recently introduced to this simple concept, but it is one that got me thinking and re-evaluating many of my previous solutions that I have built within CRM and elsewhere. When attempting to provide a potential solution to a requirement within CRM, you should try and put forward two solutions (where possible): a solution that can be achieved using out of the box functionality and one that requires bespoke coding to resolve. It may be that the first solution requires considerable time to build within CRM, but doing it this way could mean your solution is a lot more readable and understandable for those going into the system in future. By comparison, your 3-6 lines of code could prove to be virtually indecipherable.

So, in conclusion, can you guess what your new “Rule” should be moving forward?

Going back to my earlier example of your CRM Developer, AKA Former Application Developer, person, you can anticipate that they will have a very good knowledge of what CRM is capable from an SDK point of view. What may be lacking is a good understanding and knowledge of application as a whole, and specific features (such as SLA’s, Business Process Flows etc.). I would invite these people, and in fact anyone who works extensively with CRM, to focus their learning efforts towards the functional side of the application, so that they can ensure they have a good grasp of what CRM is capable of doing with, potentially, just a few mouse clicks. And, finally, to always think twice and consider alternative solutions before deciding on the best option – for everyone involved.

I was having a chat with a colleague recently about the new Interactive Service Hub (ISH) in CRM, in particular the new entity forms that are used as part of this. One of the questions that came up was “From a form scripting point of view, do ISH forms let you utilise all of the same references, properties and methods available as part of a Main form?”. As is generally the case in these situations, we can turn to our good friends TechNet and MSDN for answers. Specifically, we are able to find out the following on MSDN:

All the form scripting events and methods supported by the CRM mobile clients (phone and tablet) are supported in the interactive service hub.

If your organisation is fortunate enough to be using CRM 2016 Update 1 or CRM 2016 Service Pack 1, then you can also utilise the following methods/events as well:

Source: https://msdn.microsoft.com/en-us/library/mt671135.aspx#Anchor_1

So what does this mean in practical terms and how should this factor into your decision to utilise Interactive Forms over standard CRM forms? Here are a few things to consider, as well as my own thoughts on the best way to proceed:

If you are on CRM 2016, then get yourself Update 1/Service Pack 1 ASAP

There are a number of important new methods that can be used for interactive forms as part of this update. For example, you get much better options when it comes to working with IFRAME controls, interacting with the currently loaded record you are working with (via getID), loading a new record form (via openEntityForm or openQuickCreate) and setting focus to a particular field on a form (via setFocus). This goes above and beyond what is currently supported via the CRM tablet apps, and it is good to see that this CRM update has added these in. Having access to these methods may help to decide whether you can safely migrate or start using ISH forms within your organisation. And, as we have seen previously, the update process to SP1 for CRM 2016 is relatively straightforward, so why wouldn’t you look at upgrading?

Be sure you familiarise yourself with Interactive Form debugging

Anyone who works with CRM form scripting will be familiar with the trials and tribulations of browser debugging your scripts via Developer Tools on your browser of choice: open up your script library, set your breakpoints and then perform the actions needed to trigger your script. Try this with the new Interactive Forms, and you will notice that your custom library is not loaded onto the form. What the fudge?!?

Before panicking too much, the good news is that scripts can still be debugged, but you just have to go down a slightly different route. The CRM Team have written an excellent blog post that covers not just debugging for interactive forms, but for all forms as well. The first two options suggested seem to be the most straight-forward way of debugging interactive forms, but you can’t help but laugh at the fact that one of the suggested options is to use functionality within Google Chrome! 🙂 Joking aside, using Dynamic JScript in the manner outlined looks to be an effective way of setting breakpoints in a familiar manner. I may have to look at trying this at some point in the future.

You cannot programmatically switch to a different entity form in the Interactive Service Hub

It is sometimes useful to change the currently loaded form that a user is presented with depending on certain conditions. For example, if a user enters certain data within a Lead form to indicate the record should be treated as high priority, you may want a new form to be opened that contains additional fields, subgrids etc. that need to be completed in order to progress the record accordingly. Within the Xrm.Page.Ui reference, we have two methods that help us achieve this objective: formSelector.getCurrentItem, which returns the GUID for the currently loaded form, and formSelector.items, which returns a list of GUID’s for all forms that the current user has access to. The bad news is that, because these two methods are not supported in the mobile app, you will also be unable to use them within the ISH. This is likely due to the fact that, similar to Mobile Forms, only one form is presented to user when using the ISH, which is dictated by the form order and the users security permissions.

ISH forms do not contain a Ribbon

This may be one of the major reasons that prevent against an en masse adoption of ISH forms in the near future. One of the benefits of using the default CRM forms is the ability to modify the the CRM ribbon in order to add, remove or modify button behaviours across the application. This is great if you decide that you don’t want your users to have access to the Delete button, need to modify the order of the buttons to match the ones that are used the most or you need to setup a custom button that performs a web server call to an external system. Again, similar to the mobile application, there is no ribbon anywhere on the ISH, which means you may be missing out on key functionality going down this route.

ISH can only currently be used with a limited list of entities

If you are hoping to get your CRM setup to use ISH for your Sales related entities, then don’t get too carried away at this stage. You are currently limited to using ISH with a specific list of CRM entities. The full list, courtesy of our good friends again, is as follows:

  • Account
  • Contact
  • Case
  • All Activity Entities (System/Custom)
  • Social Profile
  • Queue Item
  • Knowledge Article
  • Custom Entities

Expect this to change in future, as one of the things that I have previously highlighted as part of Update 1/Service Pack 1 was the ability to add Feedback onto any entity within CRM, including custom ones. It would make sense that the Sales side of CRM gets some love and attention to include Leads, Opportunities etc. as part of ISH (so we may not even call it this if that happens!).

Conclusions or Wot I Think

It is clear that, whilst some of the headline benefits of using ISH are clear – visual experience, ability to drill down to individual records and efficient record filtering – , there are some very crucial and important technical limitations with the feature that need to be factored in before you decide to just completely migrate across to ISH. I would say that if your organisation has not been extensively customised to utilise form level scripting and other types of bespoke development work, then you can perhaps get away with making the jump. By contrary, you should be holding off and evaluating your existing customisations first to see if a) they are supported/unsupported by ISH or b) if there is some way to drop certain form scripting, ribbon customisations etc. in favour of using something default within CRM (for example, a Business Rule instead of a Jscript function). It could be that you can ditch a whole load of code that is not required as part of this exercise and instead utilise base functionality within CRM, something which is always preferable.

One thing I have been wondering about is the eventual aim with the ISH: is it intended that this will eventually replace the existing CRM user experience or will it continue to just be an alternative way of using CRM? It will be interesting to see how the feature is developed over the next couple of releases of CRM; one of the key indicators of this replacing the “old style” CRM forms is if we start to see all form scripting options made available in ISH and the introduction of the Ribbon.

In the meantime, make sure you do check out ISH at some stage, as the potential of setting up a visually attractive reporting and day-to-day application tool is huge. Just don’t let your Sales team see it yet, as you will end up disappointing them!

I was interested to read on TechNet that it is now supported to perform a Multiple-Server role installation of Dynamics CRM 2016 on Windows Server 2012 R2 instances that are configured in Core installation mode:

With the exception of the Microsoft Dynamics CRM Help Server and Microsoft Dynamics CRM Reporting Extensions roles, you can install any Microsoft Dynamics CRM 2016 Server server role on a Server Core installation of Windows Server.

Source: https://technet.microsoft.com/en-us/library/hh699671.aspx

At this stage you may be asking, “What is a Core installation of Windows Server 2012 R2?” or “Why would it be preferable to install CRM on a Core Server?”. Starting from Windows Server 2008, server admins can choose to install Windows Server without a GUI interface and without most of the common features that you would expect from a Windows Desktop environment. All you are able to see and interact with if you choose to log into a Windows Server core is the following:


I would imagine that most novice service admins (like me!) would start panicking at this stage…

The idea behind Core installations is that the server would be administered remotely from a server/desktop environment (using Server Manager, Powershell etc.), with it being really unlikely that you would need to logon or remotely connect to the server via remote desktop connection. As a Core installation is missing pretty much everything you would expect from a standard Windows working environment, it is potentially ideal for scenarios where you have limited resources within your virtualised server environment. Alternatively, if you are intending to deploy a resource-intensive application to the server (like Dynamics CRM!), ensuring that the application has access to as many system resources as possible could be desirable. More information about Core installations, including their supported roles/features, can be found on this helpful MSDN article.

So lets go through the process of setting up a Windows Server 2012 R2 Core Installation and then performing a CRM installation on the machine for all roles, with the exception of the ones highlighted above. We’ll take a look at some of the options available to us as part of a silent install and evaluate to see what the benefits are for an organisation to deploy On-Premise CRM in this manner:

  1. To start off, we need to get our Windows Server 2012 R2 instance setup. The installation of this is really straight-forward and simple, so will not be covered in-depth. The only thing you need to note is that Server Core Installation option needs to be specified, as opposed to Server with a GUI, as you go through the required steps:ServerCore_Setup
  2. Once your server is setup and you have logged in for the first time, you will need to get the server joined to the domain that will be used for your Dynamics CRM instance. Fortunately, this can be rather straightforwardly done in Server Core by using the SConfig command on the prompt window. Type in the following in the command prompt window and hit return:


The command prompt window will turn blue and change to resemble the following (image courtesy of Technet):


At this point, type 1 and hit enter, following the instructions in order get the Server connected to your target domain. A restart will be required as part of this. An (optional) step before restarting is to also rename the Computer to something more description e.g. CRM-SERVER.

  1. Once your server is on the Domain, you can disconnect from the Core server for now. In order to get underway with the installation, there is some prep work that needs completing first, which will require having the following files downloaded:
      • Microsoft Dynamics CRM Installation executable (.exe)
      • A configuration .xml file for the install. This is what the installer will refer to during the installation process for all of the required options. For this example, we will be using the following .xml file:

    <Patch update="true"></Patch>
    <Database create="true"/>
    <Reporting URL="http://MySSRSServer/MyReportServer"/>
    <basecurrency isocurrencycode="GBP" currencyname="GB Pound Sterling" currencysymbol="£" currencyprecision="2"/>
    <Organization>My CRM Organisation</Organization>
    <WebsiteUrl create="true" port="5555"> </WebsiteUrl>
    <InstallDir>c:\Program Files\Microsoft Dynamics CRM</InstallDir>
    <CrmServiceAccount type="DomainUser">
    <SandboxServiceAccount type="DomainUser">
    <DeploymentServiceAccount type="DomainUser">
    <AsyncServiceAccount type="DomainUser">
    <VSSWriterServiceAccount type="DomainUser"> 
    <MonitoringServiceAccount type="DomainUser">
      <SQM optin="false"/>
     <muoptin optin="true"/>

Both files, once ready, should look something like this:


  1. The next step, presumably the trickiest, is actually getting the installation files onto our Core server. As we saw, on the Core installation we have limited command line functionality, making it impractical to simply “copy & paste” the files across. Fortunately, Core installations are configured so that the root drive can be accessed over a network connection; meaning that we can drop our files anywhere on the C:\ drive and access them via the cd command on the prompt window. To begin with, we will navigate to our computer using Windows Explorer on our other machine, replacing the JG-CRM with the name of your Core server:ServerCore_Setup4We can then navigate through and create a temporary folder on the drive root where we can move across all of our required files:ServerCore_Setup5Finally, because the CRM2016-Server-ENU-amd64.exe file is a self-extracting executable, we need to first extract all of the files into a temporary location on our non-Core server; then, ensure that all of these files are copied across to our Core Server, along with our config. xml file:ServerCore_Setup6
  2. With everything copied across, we can begin the installation. Going back onto our Server Core, we first need to navigate to the location of our installation folder using the cd command:ServerCore_Setup7

Next, we can run the CRM setup executable (SetupServer.exe), specifying the following required parameters:

/Q – Quiet Mode installation

/config C:\CRMInstall\CRMServerInstall_Config.xml – The file path to the config XML file that was copied across earlier


  1. Once we hit return on the above, the command will be accepted and you will immediately be given control back to the command prompt window: ServerCore_Setup9At this stage, you may assume that something has gone wrong. But don’t panic – this is just a result of specifying a quiet mode installation. CRM will begin installing in the background and stop if any errors are encountered. Progress can be monitored by reviewing the CRM setup log files from our other server, by navigating to the currently logged in users AppData\Roaming\Microsoft\MSCRM\Logs folder:ServerCore_Setup10
  2. Assuming your installation has been completed successfully, the following Server Roles will now be available on your Server Core:
    • Web Application Server
    • Organization Web Service
    • Discovery Web Service
    • Asynchronous Processing Service
    • Sandbox Processing Service
    • Deployment Web Service

The Help Server role will not have been installed, so therefore we must run the setup for this on another non-Server Core server. The Reporting Extensions role would need to be installed on the server that has your SSRS instance, so therefore it could not be installed on our Server Core server used above. I have also deliberately left out the Deployment Tools role as part of the above, which I would strongly recommend is installed on another Windows Server instance (for ease of access more than anything). The process is the same as part of any standard CRM installation and, therefore, will not be covered as part of this post.

Thoughts & Summary

Some of the more obvious benefits of having a Server Core CRM deployment have already been hinted at. For example, I think it is definitely useful to be a in a position where you can ensure that your CRM deployment is completely free from competing with other Server resources; a Server Core installation allows you to achieve this aim quickly and easily, in a way that is fully supported by Microsoft. Installing CRM in this manner also presents some interesting opportunities for managed hosting providers, as the manner of deployment and installation (via quiet mode installation) could be easily automated in order to enable re-sellers to quickly roll-out hosted CRM instances to their customers.

Taking a look at the other side of the coin, installing CRM via this route definitely requires some patience and perseverance. I encountered several issues during installation which cancelled the install entirely, due to incorrect Service Account Details, lack of account permissions etc. It will therefore take you a number of attempts before you can start to identify the common problems that need to be dealt with before commencing the silent installation, which would ideally need to be dealt with via PowerShell script automation or similar. I would also question why it is not possible to do a Full Install (minus Reporting Extensions) on a Server Core instance. My assumption would be that the Help Server & Deployment Tools rely on Windows Server features that are stripped out during a Core installation. If your ultimate aim is to minimise hardware costs by utilising Server Core, then having to factor in additional servers/hardware for an additional Windows Server on top of this seems excessive. You would then also begin to question why you would just not use a standardWindows Server instance to start with. Finally, there doesn’t appear to be any (obvious) means of specifying specific server roles to install as part of the silent installation. This kind of defeats the whole purpose of using Server Cores to scale out the workload of your CRM server across multiple Windows Servers.

In conclusion, should you be opting to have a CRM Server Core installation in the near future? I would say “not yet” for the simple reason that you cannot select specific Server Roles to install as part of installing CRM in this manner. In my mind, this eliminates one of the most obvious benefits of marrying together CRM and Server Core. Perhaps in future, when/if you can specify individual Server Roles in the config file (or if someone can correct me in the comments below!), this will become something that can be looked at more seriously. For now though, you can save yourself the hassle.

It is sometimes desirable to grant Send on Behalf permissions in Exchange for users who are accessing another mailbox in order to reply to email messages. Some typical scenarios for this may include a personal assistant who manages a company directors mailbox, a group of users who manage a central support mailbox or for ad-hoc scenarios, such as when a colleague is out of the office. Send on Behalf permissions provide the best level of courtesy when responding to an email by letting the person know that someone else is answering an email addressed to an individual, and I would say it is generally the more recommended approach compared to granting Send As permission.

Within Office 365/Exchange Online, we can very easily grant Send on Behalf permissions for a standard user mailbox (i.e. a user that has been granted an Exchange license on the Office 365 portal) via the user interface; just go into the mailbox in question, navigate to mailbox delegation and then simply add in the users who need the required permissions:


Then, give it twenty minutes or so and then the user can then send as this user from the From field in Outlook successfully – nice and easy, just the way we like it 🙂

But what happens if we wanted to grant the very same permissions for a shared mailbox? Say that we had an IT support help desk with a shared mailbox that several different users need Send on Behalf permissions for. Within the Office 365 GUI interface, we have options only to grant Send As and Full Access permissions:


So, in order to accomplish our objective in this instance, we need to look at going down the PowerShell route. Microsoft enables administrators to connect to their Office 365 tenant via a PowerShell command. This will then let you perform pretty much everything that you can achieve via the user interface, as well as a few additional commands not available by default – as you may have already guessed, granting Send on Behalf permissions for a shared mailbox is one of those things.

Microsoft have devoted a number of TechNet articles to the subject, and the one found here is an excellent starting point to get you up and running. The salient points from this article are summarised below:

  • Ensure that the latest versions .NET Framework and Windows PowerShell are installed on your 64 bit Windows machine. These can be added via the Turn Windows features On or Off screen, which can be accessed via the search box on your Windows Start Menu or in Control Panel -> Programs and Features -> Turn Windows features On or Off,
  • Download and install the Microsoft Online Services Sign-In Assistant
  • Download and run the Azure Active Directory Module for Windows PowerShell

Once you’ve got everything setup, open up PowerShell and run the following script, altering where appropriate to suit your requirements/environment:

# Remove result limits due to console truncation


# Connect to Office 365. When prompted, login in with MSO credentials

Set-ExecutionPolicy Unrestricted -Force 
Import-Module MSOnline  
$O365Cred = Get-Credential  
$O365Session = New-PSSession –ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $O365Cred -Authentication Basic -AllowRedirection  
Import-PSSession $O365Session -AllowClobber  
Connect-MsolService –Credential $O365Cred

# Add additonal users to Send on Behalf permissions for mailbox. add= list if a comma seperate list. Each email address should be in double quoted brackets

Set-mailbox ‘MySharedMailbox’ –Grantsendonbehalfto @{add="john.smith@domain.com"}

# Confirm that user has been succesfully added to send on behalf permissions for mailbox

Get-Mailbox 'MySharedMailbox' | ft Name,grantsendonbehalfto -wrap

# Display exit script (to keep window open in order to view the above)

Read-Host -Prompt "Press Enter to exit"

The nice thing about this code snippet is that you can grant multiple users Send on Behalf permissions at the same time, which is really handy.

Based on my experience, the above has been a pretty regular request that has come through via support in the past. I am unsure whether this is common across different organisations or not; if it is, then I am really surprised that the Office 365 interface has not been updated accordingly. The important thing is that we can ultimately do this in Office 365, as you would expect via an on-premise Exchange Server. As such, organisations can be assured that if they are planning a migration onto Office 365 in the near future, they won’t be losing out feature-wise as a result of moving to the platform. And, finally, it is always good to learn about something new, like PowerShell, so we can also say that we’ve broadened our knowledge by completing the above 🙂


When I first took a look at some of the additions I was looking forward to as part of the CRM 2016 Spring Wave, I made reference to the new Email Signature feature. At the time, there did not appear to be any way of accessing this via the GUI interface within CRM; this is despite the fact there were, clearly, new system entities in the system corresponding to Email Signatures. There appears to have been some small update or change since my original post however, as it is now available within Online/On-Premise 8.1 CRM instances 🙂 . To take advantage of the new feature depends on what version of CRM you are running:

Once you’ve finished updating, you are good to go. To then setup an Email Signature for your user account, you will need to do the following:

  1.  Navigate to the Email Signature window within CRM. This can be accessed in either 1 of 2 ways:
    • The first is via the Set Personal Options screen, on the Email Signatures tab:1 2 3
    • The second is via the Sitemap Area, in Settings -> Templates -> Email Signatures:9 10
  2. Regardless of how you have got there, press the New button to open the New Email Signature window:154
  3. Give your signature a name and then populate the text area with your desired signature. You can make use of the rich text formatting in order to style your signature. Or, alternatively, you can copy & paste your signature from another application (Word, Outlook etc.):5
  4. Once you are happy with your signature, press Save. At this point, the signature will now be available whenever you create a new email record. However, in order to make the signature appear automatically whenever you draft a new email, you will need to press the Set as Default button:6If you need to revert this at any point, then you can use the Remove Default button, which replaces the above button:7
  5. Press Save and Close to finish setting up your signature. It will now be visible within the Email Signature subgrid view:8 11
  6. Now, when you navigate to create a new Email record, your newly created signature will be visible on the email:12
  7. If, for whatever reason, you need to select a different Email Signature, then press the Insert Signature button, which will then prompt you to select a new Email Signature to use:1413

I am really glad that this feature has finally been added to CRM, however…

There appear to be three glaring issues, that really need to be addressed in order to make Email Signatures work better:

  • Email Signatures are only configurable on a per-user basis. What that translates to is that if one user creates an email signature and sets it as their default, another user can log in and see this, but cannot apply it to themselves or set it as their default; if the second user wanted an email signature, they would need to create one manually. The implications for this should be fairly obvious, and I find it somewhat confusing that there is not way to setup a common template that can be then be applied and customised individually for each user on CRM.
  • There is no option, unlike Email Templates, to insert dynamic Data Field Values. So you cannot, for example, populate an e-mail signature based on information from the Job Title field on the currently logged in User account. This makes the feature impractical as a central Email Signature management tool; instead, you would have to go through the potentially rather tedious task of setting up Email Signatures for every user account on a system. Not so bad if you have a dozen or so users on your CRM instance, but if you have hundreds of users…you get the point.
  • Whilst recently studying for the CRM 2016 Service exam, I was really impressed to see that the Knowledge Article feature had been given a face lift in line with the new Interactive Service Dashboard. In particular, the text editing functionality has been improved significantly, with a range of new text editing options – many of which are not included as part of creating an Email Signature. Below is an image highlighting each of the new text editing features not available on Email Signatures, but available as part of the enhanced Knowledge Article functionality:16As you can see, there are a number options as part of the above which would be incredibly useful from a Email Signature creation point of view – Insert Image, Font Colour and View Source (perhaps the most crucial, if your organisation uses HTML signatures). I wonder why, therefore, the new Email Signature feature was not modeled in the same vein as the above.


Previously, in an attempt to replicate email signature functionality, the recommended approach was to setup an Email Template. This is beneficial when it comes to larger CRM deployments, as the dynamic data fields functionality can be utilised when creating a common template. The introduction of the new Email Signature functionality does not, in my view, mean there should be a change to this approach. I think if your CRM deployment contains a small amount of users and you have a very simplistic, existing email signature, then you can perhaps get away with using this new feature without causing yourself too many problems. Until the above issues are addressed however, I would not recommend migrating away from what you are using currently to provide email signature functionality within your CRM. This is a real shame, as I was hoping the introduction of this feature would resolve some of the headaches that I have encountered previously working with complex email signatures in CRM. Fingers cross we see Email Signatures get a bit more love and attention as part of the next major release of CRM.