Did you know that the CRM SDK contains a WebsiteCopy tool, that can be used to backup/migrate your CRM portal website? I was surprised actually, as there is no page on the CRM Setup & Administration website that refers to it. When I initially started looking more closely at the CRM portals release as part of the Spring Wave update, one of my first questions was “OK, portals are great! But how can I deploy my development portal site out to a production system when it’s ready?”. As a best practice approach, you will always want to ensure that you have distinctly separate development and production environments for any system that your business is using, and portals are no different in this regard. At first, I was concerned that there did not appear to be any “supported” mechanism for migrating development portal content into production environments; utilising the WebsiteCopy tool helps to overcome this issue and saves you from having to manually re-create records within your production CRM environment. Let’s take a closer look at how to get the tool, use it in practice and also review some of the supported scenarios that it can potentially assist with.

How to obtain the WebsiteCopy tool

In a rather counter-intuitive step, you will need to download the Dynamics CRM 2015 SDK. This is because the tool is not available whatsoever within the 2016 SDK. This seems like a rather strange oversight, so I would expect this to eventually be addressed as part of a future SDK release. Indeed, even the official MSDN page for this tool is listed as being only applicable to CRM 2011, 2013 & 2015. The 2015 SDK can be downloaded from here. Once you’ve got it and extracted it successfully, the tool can be found in the Bin folder in the root directory:

1

It is also worth pointing out that this tool is an exact copy of the Website Copy Tool provided by Adxstudio, which is obtainable via an installation of Adxstudio portals. Users of this tool should, therefore, face no challenge using the SDK version of the tool.

Using the tool

Due to simplistic nature of the wizard tool (and the fact that there are already well-documented walkthroughs available for both import and export scenarios), I will not go into detail documenting the entire process from start to finish. However, it is worthwhile pointing out the following:

  • There appears to be a bug on the Connect to Server screen where, after specifying your credentials and hitting Enter on your keyboard, the application thinks that you are pressing the ‘Go‘ button as opposed to ‘Next‘; clearing the credentials you have entered in the process and essentially going back a step: 5 6 7It took me a good half an hour or so before I figured this out, so make sure you hit the correct button!
  • When prompted to provide a Name value when importing your portal, the value can be anything you want it to be – the Website record’s Name field will be populated with this value in CRM on import.
  • I would generally recommend exporting to XML first, and then running the wizard again to import your newly created XML That way, you can double-check to ensure that you have run the initial export correctly and obtain a backup of your entire website in the process.
  • Exporting the cmd script at the end of the wizard is recommended if you intend to run the same export/import process frequently. For example, if you are running daily backups of your in-development website, then running the script instead of the wizard each day can save you some time.
  • Be prepared to put the kettle on as the import/export process can take some time.

Now that the website and all associated records are in CRM, how do you set this as your live website?

You will need to go to the configuration page for your CRM portal, and change your website record to point to your newly imported website. This is the same page you see when you first setup your portal, and can be accessed from the CRM Online Administration Center -> Applications and then Manage from your Portal Add-On subscription:

2

 

Then select your newly imported website from the Update Portal Binding drop-down:

8

Note that your changes may not take effect immediately after saving and that you will likely need to attempt the old “turning it off and back on again” trick using the Change Portal State dropdown:

3

As an additional bonus, the tool can also be used in the following scenarios:

  • Backup an Adxstudio website to a CRM Online portal deployment
  • Backup a CRM Online portal to an Adxstudio website (On-Premise/Online CRM)

To prove this, I did a test importing the ghastly looking portal, previously created as part of a previous post on Bootstrap templates. This was originally created using Adxstudio and I was able to successfully import this into CRM portals, in all its horrid glory 🙂

4

By covering both of the above scenarios, the tool instantly becomes a lot more powerful and versatile – enabling you to very quickly get your existing Adxstudio website setup as a CRM portal site. It also gives portal developers the flexibility to setup their own development Adxstudio environment, safe in the knowledge that they can straightforwardly migrate these across to CRM portals when they are production ready. Note that the above test does not confirm whether or not bespoke Adxstudio customisations via custom generated ASP.NET pages etc. will definitely migrate across 100% to CRM portals and that the steps involved in changing/modifying the bindings for Adxstudio differ significantly from CRM portals.

Conclusions or Wot I Think

CRM portals, as a product offering, is still in its early life cycle stages. As such, it is reasonable to expect that clear and broad documentation that covers the types of scenarios discussed in this blog post (e.g. managing CRM portal development environments) is not yet forthcoming and that some trial and error may be involved in figuring what to do (it wouldn’t be fun otherwise 🙂 ). What is good to know is that Microsoft has not made a conscious decision to restrict or remove some of the existing tools available for Adxstudio and that they “just work” with CRM portals. This is perhaps a rather obvious assumption, given that both products are technically identical. Nevertheless, it is good to know that those who are venturing into CRM portals for the first time can very easily get running with tools, like the WebsiteCopy Tool, when planning, developing and rolling out solutions for businesses who have taken the plunge early on with CRM portals.

I have been really excited recently, as I began working more closely with ADXstudio & CRM Portals. This was perhaps one of the more exciting new features introduced as part of the CRM 2016 Spring Wave earlier this year and presents a major step forward for the CRM product. Now, businesses can start to leverage their CRM and its data in developing professional, accessible, customer and/or partner facing websites that integrate natively with your existing CRM system and processes.

One of the first challenges when getting to grips with portals is how you go about changing the OOB design of your site – for example, how do you modify the colour for a background or a particular button? Both products utilise Bootstrap to enable portal designers to very quickly develop professional looking portals that are customised to suit particular businesses design/theming preferences. In addition to this, as outlined on ADXstudio’s website:

By using Bootstrap’s layout system, it’s possible to develop a single site that presents an appropriate interface to all devices your customers might use.

In the days where mobile responsiveness is an absolute requirement for website projects, Bootstrap provides a framework that ensures a consistent UI experience is maintained at all times for your end users. But, if you are scratching your head at just how to start working with Bootstrap (like I recently was!), it can be a major hurdle figuring out how to begin styling your portal. In this week’s blog post, I will take a closer look at what Bootstrap is, what “shortcuts” are out there that can greatly speed up developing your first Bootstrap template and how you go about applying this to your custom portal site:

What is Bootstrap?

Bootstrap was originally developed by Twitter but has since become an open-source project, on its 3rd major version. The Bootstrap website contains a nice little summary around the history of the project and its interesting journey from internal project to open-source release:

Bootstrap was created at Twitter in mid-2010 by @mdo and @fat. Prior to being an open-sourced framework, Bootstrap was known as Twitter Blueprint. A few months into development, Twitter held its first Hack Week and the project exploded as developers of all skill levels jumped in without any external guidance. It served as the style guide for internal tools development at the company for over a year before its public release, and continues to do so today.

Source: http://getbootstrap.com/about/

I was actually surprised to learn about its popularity, having not had any previous exposure to it, and its status as the almost de-facto standard in website design circles.

Creating your first Bootstrap Template

Microsoft’s article on portal theming (replicated from ADXStudios original article) suggests a few different websites to try in the first instance. We’ll take a closer look at 3 of the websites mentioned here that enable you to customise a Bootstrap template from scratch, and then at an alternative route not mentioned on either website:

Official Bootstrap Customizer

Via the official Bootstrap website, you can create your own custom bootstrap template. As pointed out in the above articles, there is no GUI interface that lets you preview your customised template; which means you have to download and apply the Bootstrap files to your website in order to get a feel for how it looks. If you’re feeling particular masochistic, then this is definitely the route for you 🙂

6

Argh, too many settings! (╯°□°)╯︵ ┻━┻

BootSwatchr

When you first start using BootSwatchr, you immediately warm to it straight away – it provides a WYSIWYG editor, enabling you to very quickly tinker around with the various settings on the default Bootstrap template, and see how they will look in a browser. VERY nice! However, I have encountered some issue using the tool on Internet Explorer/Microsoft Edge, particuarly when it comes to the most crucial bit – exporting your BootStrap template .css file using the ‘Get CSS…‘ button. This is definitely one of the tools you should check out in the first instance, but just be aware that it may not work correctly on your browser of choice.

7

Code editor? Check. WYSIWYG view? Check. Instant applying of changes to the preview? Check. Full marks!

BootTheme

What is encouraging when you first start using BootTheme is that it looks to be constructed in the same vein as BootSwatch. However, I have had real trouble figuring out how to use this tool, as it is initially quite daunting figuring out where to start. I think with some dedicated time and learning, this could be a really effective tool to use when building your Bootstrap templates, but perhaps not the best beginners tool.

8

So er, yeah, looks pretty good – where do I start? :S

PaintStrap/COLOURLovers

These tools are the ones that I have used when creating Bootstrap templates, and used in tandem, are quite effective in creating a Bootstrap template that conforms to specific branding requirements. You start off by creating a ColourLovers account, which lets you then create a “colour scheme” that can be used in PaintStrap. A “colour scheme” is essentially a collection of up to 5 different colours that you want to use on your BootStrap, which can be generated very easily using the ColourLovers website. Simply go to Create -> Palette, specify your colours, give it a descriptive name and save onto your profile:

1011 12

Once you’ve saved your COLOURLovers template, you then copy across the 6 digit code for the template into the PaintStrap 3 step wizard. This can be found within the URL of your selected template:

13

Which is then entered onto PaintStrap:

14

Then, on Step 2, you can start to customise which colours will appear where on your BootStrap – the nice thing being that you are not restricted to just the colours on your template and you can get a partial and full-screen preview of your template as you build it:

9

When you are happy with your template, click the ‘Generate CSS!’ button to download your BootStrap .css file. You will want to grab the bootstrap.min.css file; this is exactly the same as the bootstrap.css file but has been slimmed down to remove line breaks, whitespace etc.

Once you’ve got your Bootstrap, how do you apply it to your portal?

Let’s assume we are using the Basic Portal, provided as part of ADXStudio; the steps are the same for CRM Portals, rest assured:

3

Navigate to the home page of your portal, ensuring that you are logged in as a Contact that has the Administrators Web Role. On the ADX widget on the top right of your page, click on New -> Child file:

1

You’ll be greeted with the Create a new child file screen. Populate the details as follows:

  • Name: bootstrap.min.css
  • Upload File: Browse and select your bootstrap.min.css file
  • Partial URL: bootstrap.min.css
  • Hidden from Sitemap: Tick the box

It should look something like this:

2

Press Save and then refresh your browser. Your new bootstrap will be applied to your site; and, because we have configured it on our home page, it will cascade automatically across our portal site:

4 5
Looks…err…interesting! I would not recommend or endorse creating a bootstrap that looks like this, but this example provides an excellent illustration of the versatility of Bootstrap.

Getting up to speed with Bootstrap may look quite daunting initially, but fortunately, there are lots of tools and resources available online that can get you running quickly with BootStrap. These tools can significantly ease your learning journey with ADXstudio/CRM Portals and also allows you to look like a website design whizz in the process 🙂

The ability to implement trace logging within CRM plug-ins has been around since CRM 2011, so it’s something that CRM developers should be well aware of. Writing to the trace log is useful for when a plug-in has failed or hit an exception, as within the ErrorDetails.txt file (available to download from the error message box window) will be a list of everything that has been written to the log, up to that point. One issue with this is, if a user encounters an error and does not choose to download this file, then this file is lost – not so much of an issue if the exception can be re-produced, but this may not always the case.

For those who are now working on CRM Online 2015 Update 1 or CRM 2016, then a new feature has been added which further expands this feature – the Plug-in Trace Log. Now, plug-in exceptions can be configured to write to a new system entity, containing full details of the exception, that can be accessed at any time in order to support retroactive debugging. The introduction of this feature means now is the best time to start using trace logging within your plugins, if you are not already. This weeks blog post will take a look at the feature in more detail, assessing its pros & cons and providing an example of how it works in practice.

So, before we begin, why you would want to implement tracing in the first place?

Using tracing as part of CRM Online deployments makes sense, given that your options from a debugging point of view are restricted compared to an On-Premise Deployment. It is also, potentially, a lot more straightforward then using the Plug-in Registration Tool to debug your plugins after the event, particularly if you do not have ready access to the SDK or to Visual Studio. Tracing is also useful in providing a degree of debugging from within CRM itself, by posting either your own custom error messages or feeding actual error messages through to the tracing service.

Just remember the following…

Writing to the tracing service does add an extra step that your plug-in has to overcome. Not so much of an issue if your plugin is relatively small, but the longer it gets, and more frequent you are writing to the service, means there is a potential performance impact. You should use your best judgement when writing to the service; not every time you do something within the plugin, but where there is a potential for an error to occur. Writing to the tracing log can also have an impact on your CRM storage capacity, something we will take a look at later on in this post.

Now that we have got that out of the way, lets begin by setting up an example plugin! 

To start writing to the Tracing service depends on how you are implementing your plugin. If you have used the Visual Studio template, then simply use this line of code within the “TODO: Implement your custom Plug-In business logic.” section:

ITracingService tracingService = localContext.TracingService;

Otherwise, you will need to ensure that your plugin is calling the IServiceProvider, and then use a slightly longer code snippet to implement the service. An example of the code that you’d need to use to setup this is as follows:

using System;

//Be sure to add references to Microsoft.Xrm.Sdk in order to use this namespace!

using Microsoft.Xrm.Sdk;

namespace MyPluginProject
{
    public class MyPlugin : IPlugin
    {
        public void Execute(IServiceProvider serviceProvider)
        {
            //Extract the tracing service for use in debugging sandboxed plug-ins.
            
            ITracingService tracingService = (ITracingService)serviceProvider.GetService(typeof(ITracingService));
        }
    }
}

Once you’ve implemented the ITracingService within your code, you can then write to Trace Log at any time in your code using the following snippet:

tracingService.Trace("Insert your text here...");

Activating Tracing

Even though we have configured our plugin for tracing, this does not automatically mean that our plugin will start writing to the log. First, we must configure the Plug-in and custom workflow activity tracing setting within the System Settings page:

TracingSettings

You have three options that you can set:

  • Off – Nothing will be written to the trace log, even if the plugin encounters an exception.
  • Exception – When the plugin hits an exception, then a trace will be written to the log.
  • All – Whenever the plugin is executed and the trace log is called, then a trace log record will be created. This is equivalent to Verbose logging.

As mentioned earlier, individual records will be written to CRM whenever the tracing service is called. It is therefore recommended only to turn on ‘All’ for temporary periods; leaving it on for ‘Exception’ may be useful when attempting to initially diagnose plugin errors. Review the amount of storage available to you on your CRM Online/On-Premise deployment in order to determine the best course of action.

Tracing in Practice

Now that we’ve configured tracing on our CRM and we know how to use the Tracing, lets take a look at an example plugin. The below plugin will be set to fire on the Post-Operation event of the Update message on the Account entity. It will create a new contact record, associate this Contact record to the Account and then populate the Description field on the Contact with some information from the Account record:

protected void ExecutePostAccountUpdate(LocalPluginContext localContext)
    {
        if (localContext == null)
        {
            throw new ArgumentNullException("localContext");
        }

        //Extract the tracing service for use in debugging sandboxed plug-ins.

        ITracingService tracingService = localContext.TracingService;
        tracingService.Trace("Implemented tracing service succesfully!");

        // Obtain the execution context from the service provider.

        IPluginExecutionContext context = localContext.PluginExecutionContext;

        // Get a reference to the Organization service.

        IOrganizationService service = localContext.OrganizationService;

        if (context.InputParameters.Contains("Target"))

        {
            //Confirm that Target is actually an Entity

            if (context.InputParameters["Target"] is Entity)

            {
                Guid contactID;
                string phone;

                Entity account = (Entity)context.InputParameters["Target"];
                tracingService.Trace("Succesfully obtained Account record" + account.Id.ToString());

                try

                {
                    tracingService.Trace("Attempting to obtain Phone value...");
                    phone = account["telephone1"].ToString();
                            
                }
                    
                catch(Exception error)

                {
                    tracingService.Trace("Failed to obtain Phone field. Error Details: " + error.ToString());
                    throw new InvalidPluginExecutionException("A problem has occurred. Please press OK to continue using the application.");

                }

                if (phone != "")

                {

                    //Build our contact record to create.

                    Entity contact = new Entity("contact");

                    contact["firstname"] = "Ned";
                    contact["lastname"] = "Flanders";

                    contact["parentcustomerid"] = new EntityReference("account", account.Id);

                    contact["description"] = "Ned's work number is " + phone + ".";

                    contactID = service.Create(contact);

                    tracingService.Trace("Succesfully created Contact record " + contactID.ToString());

                    tracingService.Trace("Done!");

                }

                else

                {

                    tracingService.Trace("Phone number was empty, Contact record was not created.");

                }
            }
        }
    }

After registering our plugin and with tracing configured for “All” in our CRM instance, we can now see our custom messages are being written to the Trace Log – when we both update the A. Datum Corporation (sample) record Phone field to a new value and when we clear the field value:

Plugin_1

Plugin_2

Plugin_3

Most importantly, we can also see that our test Contact record is being created successfully when we populate the Phone field with data 🙂

 

Plugin_4

Now, to see what happens when an error is invoked, I have modified the code above so that it is expecting a field that doesn’t exist on the Account entity:

Plugin_5

Now, when we attempt to update our Account record, we receive a customised Business Process Error message and window:

Plugin_6

And we can also see that the precise error message has been written to the trace log, at the point we specified:

Plugin_7

Last, but not least, for On-Premise deployments…

One thing to point out is, if you are using On-Premise CRM 2016 (both 8.0 and 8.1), then for some reason the trace log will not work if you do not run you plugin within sandbox isolation mode. I’m not the only one experiencing this, according to this post on the Dynamics CRM Community forum. Switching my test plugin to sandbox isolation resolved this issue. A bit of a strange one, and as Srikanth mentions on the post, it is not clear if this a bug or not.

Conclusions or Wot I Think

Trace logging is one of those things where time and place matter greatly. Implementing them within your code obsessively does not return much benefit, and could actually be detrimental to your CRM deployment. Used prudently and effectively though, they can prove to be incredibly useful. The scenarios where I can see them returning the most benefit is if your plugin is making a call to an external system and, if an error is encountered during this process, you can use the Trace Log to capture and store the external application error message within CRM for further investigation. Trace logging can also prove useful in scenarios where an issue cannot be readily replicated within the system, by outputting error messages and the steps leading up to them within the Trace Log.

In summary, when used in conjunction with other debugging options available to you via the SDK, Trace Logging can be a powerful weapon to add to your arsenal when debugging your code issues in CRM.

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!

Header

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.

Conclusions

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.