CRM Development – As easy as making a cup of tea?

Last weekend I attended the Dynamics 365 Saturday Summer Bootcamp in London; this was a great event full of opportunities to network, engage and learn, and I am very grateful to the organisers for putting on the event.  Whilst at the event I was speaking to someone who told me that he was currently working as a business analyst but was considering training to become a CRM Functional Consultant and it got me thinking about the importance of business analysis skills to me in my role.

Always ask “Why?”

Before I became a CRM Consultant I studied Law at university, and I’ve trained as an ISO9001 internal auditor in previous job roles.  This background has provided me with a strong ability to analyse and understand business process, though my biggest asset is probably my incessant asking “Why?”.

I’ve spent countless hours developing solutions for CRM that then go unused by the business after deployment, and I could’ve saved so much of this time if I’d just asked “Why” a bit more.

  • Why do you need this solution?
  • Why are you recording this information?
  • Why does the process work like this?
  • Why can’t we use existing functionality?

The key thing is to make sure you have enough detail so that you have a full understanding of the requirements before you even commence development.  Think of it as a modern version of “measure twice, cut once”.

Creating Process Flowcharts

I have a logical mind, so I like to document all of my processes in flowcharts before I get underway with development.  I find a flowchart helps me to keep my thoughts in check and guides me in my development of system updates.  A good flowchart should be comprehensive but clear; it should provide you with all of the steps in the process and should have a clear, logical path to follow.  Anyone who has used Visio in the past can probably attest to the simplicity of creating flowcharts, though I think there is a bit of an art to making a good flowchart.

In order to demonstrate the level of detail I look for in a flowchart, I thought it would be useful to think of it in terms of a process that everyone can understand – making a cup of tea!

How to make a cup of tea

I know what you’re thinking – everyone knows how to make a cup of tea, it’s a waste of time to document the process.  Fortunately, this is a really simple process to document:

Simple Process

So that’s us done right?  If only it were that easy…

I’ve experienced plenty of processes like the above, they are a weak attempt at documenting how a process works, and miss out quite a lot of the detail.  For a start, if you boil a kettle without adding water to it, you’re gonna have a bad time.  I’ve yet to make a cup of tea for a group of people without there being variables involved, some people want milk in their tea, and some people want sugar.  Some want both, some want neither.  So let’s start over and create a process that includes these variables:

Simple Process with variables (1)

Ah, that’s better!

This is a much more detailed process, and accounts for the variables at different steps.  A little bit of extra thought, and asking a few more questions about the process has helped us to capture a lot more information and ensure the process accurately reflects the actual work being completed.

Unfortunately, I think this is still too simple.  There are lots of different types of tea, and they have different preparation processes.  In most businesses, their processes may have multiple divergent paths based on decisions taken at different parts of the process, and this can have a massive knock-on effect to your development if you don’t account for it at the planning stage.  I’ve lost so many hours to poor planning and a lack of understanding of the needs of the business when I’ve been creating my solutions.  Trying to unpick a solution after implementation can be time-consuming, painful and frustrating.

A comprehensive tea making flowchart might look like the below:

Comprehensive Process

This process accounts for multiple variables, divergent paths, and includes a lot of detail that would help me understand what I need to do to make sure my system can account for all of the steps.  It is possible to make this even more detailed if you wish, though you also have to know where to draw the line and not to add complexity for no additional benefit

Conclusions

As I’ve hopefully demonstrated above, it’s really easy to make a simple process, but there are risks involved in basing your system development on poor information.  Spending the time at the start to ensure that you fully understand the needs of the business and the process problem you’re creating a solution for will ensure that your development time will not be wasted.

At the very least, after reading this I hope you know how to make a cup of tea!

 

Designing CRM Forms for User Experience

Introduction

In order to ensure User Adoption of CRM is successful and that the system is delivering results for Users, it is important to ensure that their experience of using the system is as painless as possible. In practice, this means removing unnecessary obstacles to enable them to find the information they need, when they need it. Whilst CRM is, by its nature, a data input system, it is important to focus on the outputs the system can deliver, and the actionable insights it can generate. A smooth and efficient user experience will help ensure that CRM becomes the point of reference for users when they are looking for data, and will drive them to embrace the system rather than relying on Excel spreadsheets and other workarounds that they may have used in the past.

Why Focus on UX?

Microsoft produced a set of User Experience guidelines in 2013, and the diagram below shows how designing an efficient User Experience benefits the business:

UX Principles
Aligning the purpose of CRM towards the end user’s needs leads to better user perception as the users consider CRM tobe giving them value by making them more efficient.  If the CRM system can be seen to be delivering value to the users it leads to wider user adoption which naturally generates a greater quantity of higher quality data.

A CRM system that has a lot of quality data can be used to generate meaningful insights and actionable intelligence, and this can drive business decisions. If the business is able to see a valuable impact from the system, then they will be more likely to sustain and increase their investment in the system development as they will recognise the return on investment they are receiving.

Microsoft have summed this up in the paper as follows:

The key take away here is this: It’s very important to focus on the value CRM adds to the end users’ day-to-day activities and how it helps them achieve their goals and objectives. If this shared purpose isn’t established early and the focus isn’t enforced through design and implementation decisions, poor adoption and overall project failure will likely follow.

In order to demonstrate these principles in practice, I’ll use some sample issues I’ve encountered in my environment in the Accounts entity, though the conclusions reached can be equally applied across any system entity.

Note: the screenshots below are from a CRM 2016 (v8.1) system, and some of the issues encountered in this version of CRM can be addressed with the upgrade to Dynamics 365.  Nevertheless, I hope it still provides valuable food for thought.

Sample Issues

For the purposes of this section, I’ll be using the screenshot below as a reference

AccountFormSample.PNG

Long lists of fields

According to Miller’s Law, humans can only understand and process information in a maximum “chunks” of 7. In practice in CRM this means that, where possible, we should try to avoid long lists of fields as they become difficult and confusing to process, unless they can be broken into smaller sections and groups that help the users to consume the data.

On the Account form above, you can see that the Account Information section on the left is comprised of a long list of over 20 fields.  The list of fields contains a number of different field types, there is not a logical flow to the fields, and they’re not grouped in a way that new and existing System Users will be able to understand easily.

Having a large list of unrelated fields also creates issues when you take into consideration the likelihood of the fields being filled in.  In the example above, different fields ralte to different Account Types (i.e. clients, prospects, etc.).  If there are large lists of empty fields this can be visually jarring for users, and it can reinforce negative behaviours e.g. not filling in fields when information is known.

Visual Clutter

The sample Account form is also quite cluttered visually. For example, a large amount of screen real-estate is dedicated to the Notes & Activities feed; the information in this section, whilst useful, is not accessed regularly and is usually of interest only in certain circumstances.

Similarly, though it is not visible on the screenshot, underneath the “Address” section there is a map that highlights the location of the selected address. This map is rarely used, often incorrect, and therefore consumes more space on the screen that could be utilised for more relevant information.

Utilisation of Sub-Grids vs. Associated Grids

There are a number of Subgrids on the Account form, however there is limited screen space to ensure all relevant data from the related entities can be displayed. For example, the Contacts subgrid in the screenshot above is situated on the right hand side of the screen, but there are a few potential issues with it:

  1. It only displays six contacts at a time. If there are a lot of contacts on the account Users would need to navigate multiple pages to find the specific contact they wanted.
  2. The list is organised alphabetically; whilst this makes logical sense, it is typically not the most useful form of sorting. For example, if the contacts were organised by Job Role, or by the amount of times contacted, etc. this would probably be more useful for Users
  3. The subgrid only displays two columns, and is therefore missing other potentially useful information that would assist users. They will have to open the Associated Grid or the individual Contacts to find the information they need

There is nothing inherently wrong with using subgrids, however if the information is used infrequently, or the amount of information that needs to be conveyed is more than can be displayed in a small grid, then it is recommended to use the Associated Grids.

Field Positions

Whilst recognising that there is a need to make space on forms for fields that are used infrequently, the position of these fields could be considered to create logical flow through the form. In an ideal scenario, the most useful fields will be closer to the top of the form, and the lesser used fields will be relocated further down. This ensures the User Experience can be optimised to minimise excessive scrolling or searching for information.

For example, the Company Profile section contains fields for Number of Employees and Annual Revenue, however they are not completed on many Accounts. The SIC code fields are also too small to display all of the information. The Primary Contact field is similarly not filled in on a lot of the records.

 

Multiple Forms with Similar Data

One of the great flexibilities of the CRM system is the ability to create multiple forms for entities, however lazy development can quickly lead to issues with this.  When creating a new Form, Microsoft “helpfully” pre-populate the form with tabs, sections and fields for you.  In order to ensure the Forms serve a purpose you should only add fields to the form if they’re required, and remove everything else.  The Account entity in this example had 7 forms available to all system users.  Whilst each form was intended to serve a purpose, the form design meant that there were a lot of repeated fields across all the forms, leading to confusion for Users about which Form they should be using.

Related Records Navigation

related Records Navigation.PNG

An oft-overlooked aspect of CRM Form design is the related records navigation section.  It’s easy to forget to update this section, and there is a limit to the customisation capabilities for this section.  In the example above the list of Related Records is not optimised to deliver best results for Users.

To reduce navigational clutter, any related records that are not likely to be used should be removed, e.g. Import Logs, Feedback, etc. The relationships should be specifically named to ensure there is no confusion (i.e. there are two “Opportunities” relationships currently visualised, but they don’t have specific descriptions.  You should also group the related records into common sections to make it easier to navigate for Users.

Recommendations

In order to address the issues highlighted above, I would recommend designing your Forms to follow, where relevant, the Microsoft guidelines for user experience design.

Some of the recommendations I would implement are:

  1. Field Label Width – set to ensure the full label of the fields are visible and not cut off
  2. Tab and Section based grouping – using Form Tabs to group related fields, and sub-grouping the data into sections within the tabs
  3. Smart Form Design – where necessary, using business rules and JavaScript functions to hide/show fields as required, and using Field Security to restrict access to fields to specific security roles
  4. Removing Duplication – on occasions where additional forms are required, ensuring they are not simply a duplicate of other forms, and are designed for a specific business need.

An example of how these recommendations have been implemented can be seen below:

NewAccountForm

For the example above, I’ve implemented the following changes:

  1. Grouped fields into common sections to make it easier to find relevant information
  2. Used the Advanced Multiselect solution to add multiselect options
  3. Removed the Address composite field.  I’m really not a fan of the composite fields, though I appreciate they can serve a purpose.
  4. Changed the “Country” field from Single Line of Text to an Optionset to ensure consistent data input
  5. Used JavaScript and business rules to show/hide fields based on selected account type
  6. Moved the Notes and Activities feed to a dedicated tab to enable it to be collapsed to save screen real estate
  7. Removed sub-grids where they were not serving a useful purpose
  8. Removed unnecessary duplicate forms
  9. Cleaned up the related records navigation (see below)

New Related Records Navigation.PNG

 

I think this approach has made the Form more usable, and it’s much easier to digest from a visual perspective.  Taking the time to understand the User’s needs helps to ensure they appreciate the system and feel that it is working for them, rather than against them.

If you’ve got any thoughts on how to improve the User Experience please add your comments below, or get in touch with me

Long Date Formatting for Date fields – A Different Way

I recently read a great blog post by Megan Walker regarding the formatting of a long date field in CRM.  Megan has explained really simply how to achieve this using JavaScript, and I’d thoroughly recommend reading her blog to see how easy it is.

I know that some people are uncomfortable even with using simple scripts so I wanted to highlight an alternative way of achieving this without using JavaScript, for those who may wish to avoid it.

I’ve previously discussed the Workflow Elements solution by Aiden Kaskela in my blog about adding team members to another team, and this is another perfect opportunity to utilise it.

Overview of date formatting workflow

One of the options in Workflow Elements is Date – Convert to Custom Text, and this allows you to build a custom text version of any date field in your entity using up to 20 components.  The components available comprise options for Year, Month, Day, Hour and Minute, as well as options for AM/PM designators, time zone display and separators.

Kaskela Date Format Options

Building your date

Creating a custom text date couldn’t be easier, you simply add the Date – Convert to Custom Text step to your workflow, then open it and select the date you’d like to convert, pick the time zone for display and then build it from the options identified above:

Buidling the Date

Once you’re happy with the custom date options you’ve selected, save and close the window then add an Update Record step to your workflow.  In the Update Record step, find the field you’d like to update with the Custom Date, then in the Form Assistant select the previous step output under local values, then select the Formatted Date option and add it to your field.

Add to workflow.png

The output of the workflow looks great and is easy to configure:

Date

 

I still wouldn’t recommend using this for every date field in your environment, but this is a handy and simple alternative to JavaScript and it doesn’t require you to open and save the record for it be triggered.  The configuration options available give you significant control over the output and can cater to most requirements.

Add Team Members to another Team

I’ve been working on a problem that’s been plaguing me for months and now, thanks to Microsoft Business Solutions MVP Aiden Kaskela and his Workflow Elements solution, I’ve finally managed to get it sorted.

The Problem

I wanted to be able to conditionally add members of one Team to another with a workflow, without hard coding the specific Users into the workflow.

My specific scenario was as follows:

If an Opportunity meets certain criteria, an Owner Team is automatically created and linked to the record.  The new Owner Team should then be updated to include Users who are in another Owner Team (the Proposals Team in my scenario).

Dynamically Add Users to Opportunity Team

Why couldn’t we just link the Proposals Team to the Opportunity I hear you ask?  Good question, it is because the Proposals Team are the minimum members of the New Opportunity Team and each Opportunity Team may have multiple other Users added to it from across the business.

We use the Teams as part of our custom integration with SharePoint; adding a User to the Team automatically assigns them specific permissions in SharePoint so we needed specific Teams per Opportunity.

I went round in circles for a long time trying to work out the most efficient solution for this, but I kept running into issues.  I was able to achieve steps 1-4 from the image above, but could never quite complete the process.  The closest I came was using the “Add User to Record Team” N:N associate step from Andrii Butenko’s Ultimate Workflow Toolkit, however this still required me to add a step per user and hard-code their name into the Workflow, which meant I would also then have to deactivate the workflow and update it if the composition of the Proposals Team changed.

I asked in the CRM Community Forum to see if anyone else could help but still ran into the same issues.  I reached out to Aiden Kaskela about a month ago to see if he could help and today he’s delivered in spectacular style

The Solution

Aiden has updated his Workflow Elements solution to include a new step – “Relationship – Associate From Query” (available from V2.1.0) which makes my scenario really simple to solve

Kaskela Workflow Solutions

Getting this step to work couldn’t be easier.  You add it to your workflow, then select the N:N Relationship Name, and then you have the option of using a System View, Personal View or FetchXML query to select the records to be associated.  For my scenario, this was triggered on the Team entity, and used a Personal View on the System User entity to find the members of the Proposals Team

Relationship - Associate from Query

I love the simplicity of this workflow step, and I can envisage a number of additional scenarios that this could be used for in my environment.  It makes it really easy to develop complex, dynamic association workflows.

Conclusion

Solving this problem has demonstrated two things to me:

  1. Dynamics CRM/365 is an amazing platform, and the flexibility it offers developers and customisers to deliver on much-needed functionality is so useful.  The system gets better with every release, and it makes it a pleasure to work with
  2. More importantly, the CRM/365 Community is incredible.  There are so many developers who create tools and plugins that they make available for free for us all to use, and they make my job so much easier.  Their creativity and generosity astounds me, and I am so grateful to them for everything they provide.

I could not recommend the Kaskela Workflow Elements solution enough.  I use it for so many applications, and this latest release makes it even better.  Please go and visit his website, download the solution and try it out; I guarantee you’ll love it.

 

Customisation Tips – Entities

Following on from my last post I wanted to share some of the tips I’ve picked up along the way related to developing new entities in Dynamics CRM/365.

The first major step in any development is the creation of a new system entity, and there are plenty of opportunities for missteps here.

Per my last post, ensure any new Entity is created from within a solution, and NOT by selecting “Customize the System”!

Ownership

Entity Ownership

The initial decision you need to make is to decide whether you need the Entity to be owned by a User or Team, or by the Organization.  This decision can be influenced by the following factors:

  • Does the entity need specific security, or will it be open to all Users?
  • Do you need to have a specific named Owner of the records in the Entity?
  • Is the entity going to be used for a reference record (e.g. preferred language, region, etc.)?

This decision cannot be changed after the entity is created, so it is important to make the right decision.  If you’re not sure, I’d always recommend selecting User or Team ownership, as you can work around this to emulate Organizational ownership, this isn’t possible the other way around.

For more reading, see this article on MSDN.

Activity Entity

The next decision you need to make is whether the entity is an Activity or not.  This is a fairly straightforward decision

If the records will have a Start Time and/or an End Time, and will be Completed by Users, then it is probably an Activity.

It’s important to remember that defining an Entity as an Activity Entity cannot be undone, and that Activity Entities don’t have security, all Users can see all Activities, so factor this into your thinking.

Primary Field

Primary Field

A simple mistake I have seen made by many developers is to overlook the Primary Field.  It’s on a separate tab, so it’s really easy to click Save and forget about it, only to regret it later.

It’s important to give it a relevant name for your entity.  The Primary Field can only be a Single Line of Text field, formatted as Text.  Update the Display Name and Name to something relevant for your new entity, also decide if you want the Field to be required or not, and update the Maximum Length. I’d also recommend adding a proper description here.

The Primary Field is used for lookups to the entity, and is the default field included in a View when you create an entity, so forgetting about it can lead to search results that look like:

NoNameEntity.PNG

Even if you’re not going to use the Name (for example if you’re creating a manual intersect entity), I’d always recommend setting it up properly.  In situations where I’m not using the Name I will always set up a Workflow or Business Rule to set the Name automatically.

Entity Options

The last thing to decide before you save your new entity is which of the options you want to select. The best advice I can give here is to untick everything, unless you are ABSOLUTELY sure that you need to keep a field ticked.  This is particularly important for the Business Process Flow, Feedback, Notes, Activities, Connections, Sending Email, Queues, and Enable for SLA fields, which cannot be disabled once they are selected.  You can always enable them later if you need them, but they create fields on your entity, and add to clutter if they’re then unused.

No Ticks

The guys over at CRM Tip of the Day have turned entity creation into a handy illustrated guide that you should definitely print out and hang up on your wall to remind you of these rules!

Once you’re happy with all of the entity options, click Save and now you can move on to adding Fields.  I’ll share my tips for Fields in my next post.

Customisation Tips – Solution Management

When I first started using CRM I made plenty of mistakes that cause me to physically cringe when I reflect on them, so I hope that by sharing some tips that I’ve picked up on my journey, I may be able to help others avoid them.

I’ve been discussing customisation best practices internally in my organisation and, since I’ve been documenting them anyway, I thought it would be worth sharing my thoughts.

Use solutions

This is probably my number one tip. If you’re doing any sort of system customisation, please put it in a solution container; NEVER make changes directly to the base solution – just pretend the “Customize the System” button doesnt exist.

Ignore the Customize the System button

By using a Solution you can avoid the dreaded new_ prefix on newly created fields/entities/web resources, etc. and use your own publisher prefix.  A solution also operates as a container for all the customisations you are making to the system, which makes it significantly easier to understand what changes have been implemented for you and anyone else who may be working on your system.

One of the biggest debates on the use of Solutions is whether you should Managed or Unmanaged. I have used both in different systems and I don’t think there is a single right answer; it all depends what is right for you in your system (though Microsoft officially recommend the use of Managed Solutions (see https://msdn.microsoft.com/en-gb/library/gg334576.aspx#BKMK_UnmanagedandManagedSolutions)

Managed or Unmanaged

There are plenty of posts by more experienced heads than I discussing the differences between the two solution types, and weighing up the pros and cons of each, so I’d recommend seeking them out for further reading.

The only real piece of advice I’d like to add is that Unmanaged Solutions are easier to manage (pun intended), and you can always convert an Unmanaged Solution to a Managed Solution in future if needs be; just be aware of the potential for unintended changes to be added to the solution by over-zealous developers during UAT or while it is live in the Production environment, leading to solution disparity.  You should weigh up the control of Managed Solutions versus the flexibility of Unmanaged Solutions in any decision-making.

Version Numbering

Aligned with the use of Solutions is to ensure you have a rigorous and consistent approach to versioning. Using version numbers makes it a lot easier to manage your solutions, and to identify issues if and when they arise.

My approach is to use the standard of Major.Minor.Release (#.##.####), as defined below:

Version Numbering

Major – this should be incremented every time you introduce some significant functionality, change the phase of the project, or if you upgrade to a new version of CRM

Minor – this should be incremented every time you release an update to the solution that introduces minor features or changes that are building on existing functionality.

Build – this should be incremented with every single release, and should cover bug fixes, etc.

There are lots of different version numbering schemes available (e.g.  Major.CRMRelease.Minor.Release, Year.Month.Day.Revision, etc.), and it doesn’t really matter which one you use –  the important thing is that you use a consistent version numbering scheme in your development, and that everyone working on your system understands the numbering scheme.  I’ve previously inherited a system developed by a Microsoft Partner who had used 4 different numbering schemes when deploying solutions which gave me no end of headaches.

Documentation

I’m sure I’m not alone in not particularly enjoying writing documentation, but also cursing out any other developers who dare to release a solution without documentation.  As important as it is to develop system updates, writing appropriate documentation is equally important.  I’m not suggesting that you include War & Peace with your releases, but adding a few notes on the release history to the solution description field will go a long way to helping both future you, and anyone else who may be working on your system

Release Notes

Having these little notes provides a perfect aide-mémoire when you come back to work on the solution in six months time, and taking the two minutes to do it now will save you hours down the line.  I like to keep a more detailed release note history to go with my solutions too; for a great example of detailed release notes you could look at ClickDimensions.

Quick Tip: To make your life a lot easier when writing release notes, the MetaData Document Generator plugin for the XRMToolBox is a lifesaver

My next post will outline my tips related to new entities, fields, views, etc.