Tag: email

CRM 2013 SP1: Case Creation and Routing – The Details

In my previous post about the new functionality included in CRM 2013 SP1 / Spring ’14 release I laid out the big picture of how case creation and routing rules relate to cases and queues in Dynamics CRM. Now it’s time to take a more detailed look at how you would actually configure these rules to automate your case creation process. There are a few limitations that it’s good to be aware of before you jump into applying these new tools in your service management scenarios.

Case Creation Rules

As illustrated in the big picture of queue and case management in my previous article, Case Creation Rules are specific to a single queue. Also, you can only have one Case Creation Rule per queue – per channel. It is nevertheless a 1:N relationship between queues and rules, since a queue can have a Case Creation Rule both for email and social activities (the latter of which are not yet leveraged in this release). The Command Bar buttons on the updated queue form, labelled “Email To Case Settings” and “Social To Case Settings”, take you to the respective rule record.

The Case Creation Rule form allows you to configure predefined conditions for case creation. Emails from unknown senders can be filtered away from case creation. Also the existence of a valid entitlement for the sender (contact) or the senders company (parent account) can be used as a filter. Finally, email related to an already resolved case can be set to generate a new case record, with a configurable “quarantine” time period. So, if you resolve a case today and the customer replies “thanks for your help”, this probably shouldn’t generate a new case, but a reply sent after 3 days to the same email thread might warrant opening up a whole new case record.

That’s all the conditions you can apply for the automatic case creation. There’s an additional entity called Case Creation Rule Item that’s found in the “Specify Case Details” subgrid. What this feature allows you to do is specify a condition on the activity record (email or social activity) and set values for the newly created case’s fields. As an example, if the email subject contains word X, you could populate the case subject lookup field with value Y. So, you can’t use these Rule Items to determine whether a case will be created or not, but you can pass along some variables from the originating activity.

The entity fields you can access in the Conditions box are limited to those directly related to the email (or social) activity. There is however one welcome exception and that is the Senders Account. This means that when the email is coming from a known contact, there’s a way to reach into the fields of the account related to the contact (related to the activity), to check variables like relationship status, customer category or other important pieces of information in a B2B service scenario. (more…)

June 3, 2014
CRM 2013 SP1: Case Creation and Routing – The Big Picture

The latest Dynamics CRM Online Spring ’14 release is now rolling out to existing and new customers (starting from the US data centers) and the on-premises equivalent of CRM 2013 Service Pack 1 ~~will soon follow~~ is now available from MS Download Center (here’s the KB article for more details about SP1). The quickest way to check if your CRM Online organization is already updated to the latest release is on the About screen, accessible via the gear icon in the top right corner. If your version reads 6.1.0.575 (or 6.1.anything) then you’ve got the Spring ’14 release available and you can proceed to the Install Product Updates menu to enable the new features.

This release, previously known by the codename “Leo”, focuses on enhancing the service management capabilities of Dynamics CRM. There’s a great “What’s New” page on CRM Customer Center that provides a detailed listing of the new features launched now, including an eBook of the changes in service management. Instead of repeating all of this information, I’ll try and provide an overview of how the features align with one another and specifically how they could be applied in real world scenarios for managing incoming service cases from customers.

Enhancements in Case Creation and Queues

I guess we’ll still need to first list the new options we need to be aware of when configuring the service module in CRM 2013 SP1 to handle emails and cases via queues. First off, there is now support for server side synchronization of emails (and other activities) between CRM Online and Exchange Online, without having to use the old Email Router technology (no support for hybrid deployments, though). Then there’s a new feature called Case Creation Rule that allows you to automatically convert an email message or a social activity record placed in a queue into a new case record. Finally, we have Routing Rules that can be leveraged for moving items into queues.

The following is my own interpretation of how these three areas are aligned in CRM 2013 Spring ´14 Update / Service Pack 1. The picture illustrates how an email message from the customer would flow through the system automatically based on the configuration of the aforementioned features. It also includes a few bullet points about the supported actions for each component. (Feel free to click on the image to view a bigger version that won’t stress your eyes so much.)

When going through the Leo release features I found it a bit challenging to get a clear view of the logical order in which the different functional areas found under the new Service Management settings menu should be applied. Also the relationships between them and the restrictions imposed on the number of records was something I only learned through trial and error. Hopefully this illustration makes it easier to identify the roles of case creation rules and case routing rules in the new release.

Rules vs. Workflows & Plugins

Looking at the picture, someone who has previously configured Dynamics CRM to be used in an email, queue and case based support process will surely find many familiar actions from the list. At the end of the day, pretty much everything here has already been possible with previous CRM versions. With those you just needed to leverage the workflow engine in the CRM platform to configure the case creation and routing activities. So, what’s really new here and why has Microsoft built this into the latest product release?

Behind the scenes, what the case creation and routing rules do is they create the workflow processes for you. This can be seen from the release documentation where the administrator of those rules is reminded about the requirement to have sufficient security roles for performing the corresponding actions via workflows. So, taking a very simplistic view, you could think of these new features available in the Service Management as a dedicated UI for configuring common process automation actions for customer service scenarios.

There’s definitely value in having these new features available right inside the core product. In previous versions, it has been far from trivial to build the necessary functionality for frequently encountered requirements, such as “email to case”. Several ISV add-ons have been developed to deliver such functionality and system customizers have surely spent a ton of time pushing the CRM workflow editor to its limits in an effort to automate the common tasks that a service organization would need to perform when managing cases in Dynamics CRM. Now there’s a new standard way to implement these processes via a method that is fully supported by Microsoft, which in turn will lead to far more customers taking a serious look at these case management capabilities in their business application platform.

It’s important to keep in mind that these new features don’t replace any of the existing CRM platform functionality. They offer a default method to configure common features, but they will not cover every possible scenario that you’ll come across in real life implementation scenarios. That means you can still use workflows and plugins to extend the process automation for service case management. For example, while a case creation rule provides the possibility to set an auto response email to be sent to the customer upon case creation, there’s nothing stopping you from doing this via familiar workflow process if more complex business logic is needed than what the new Service Management UI in CRM makes available.

In the next blog post I will take a more detailed look at how the case creation and routing features can be leveraged in practice, so stay tuned!

May 24, 2014
Dynamics CRM Reminder Workflows Done Right

A very frequent requirement that customers present for their CRM system functionality is that they will get automatic reminders from it when an item recorded into the database requires their attention after a specific date is reached. This might be a hard, physical date like a contract expiring or a softer variable such as a follow-up date on an open opportunity. Since receiving email notifications from various online services is such a ubiquitous pattern for process reminders these days, it’s only natural that the CRM system is expected to behave the same way.

What sounds like a straightforward thing to implement with the help of the Dynamics CRM workflow processes isn’t necessarily such an easy task – at least if you want the reminder workflow to operate correctly under all the possible circumstances. In a scenario where the reminder is set by the user via a value entered into a date field there’s a number of other variables that you should take into consideration besides that single data entry. For a developer who is used to dealing with user inputs and exceptions this may be just another routine task of figuring out the logic surrounding the reminder date variable, but for a functional consultant who typically works more directly with the end users and mainly just points & clicks in the CRM customization menus for building out the required functionality this may not be such familiar territory. I’ll be the first to admit that I struggle with workflow logic a lot.

Given how much time I’ve spent wondering “how should I do this” when it comes to CRM workflows, the wording of this blog post’s title is pretty bold. Is there really a single right way to build reminder workflows and do I know nearly enough about them to claim the privilege of defining the proper design pattern for them? This is actually just more of a provocation through which I’m hoping to gather feedback on the inevitable shortcomings of this post via the comments section. Another reason behind this choice of the title is that I stand on the shoulders of giants when it comes to my knowledge about CRM workflows, meaning everything I know about them I’ve read from blogs elsewhere and I’ll try my best to highlight the articles deserving most attention via linking to them as we move forward.

In this post I’ll use a scenario where the opportunity record has been extended with a custom follow-up date field. Entering a date into the field is done by any user who has access to update the opportunity. When the follow-up date is reached, a reminder should be sent to the owner of the opportunity, but only if the record is still in an open status, since won or lost opportunities don’t require reminders anymore. Sounds logical? Good, then let’s start working on implementing all the required business logic onto the Dynamics CRM workflow editor canvas.

Start conditions

The first thing we need to decide on when designing workflows is defining the criteria on when should we be performing any actions to begin with. In our scenario, any moment a user could enter a value into our reminder date field is a potential trigger for our workflow logic, so we should have the process started both on the create event of the record as well as the change event of the field in question.

Since we’re dealing with an optional field that doesn’t necessarily contain any value, we should check this right away. It’s not enough that there is a value in the field, but it also needs to be something we can act upon. There are two general things that interest us: 1) is the record sill active (meaning does it require any reminders) and 2) is the reminder date in the future. There’s no point in us sending an email to a user right away if he or she mistakenly enters a date that’s passed last month already, so better to just ignore any such input values and do nothing in this case.

Wait conditions and stopping the workflow

If we’ve determined that there is a valid reason for our workflow to take note of the event to which it has been attached to, the next step is to… just wait. No, I didn’t mean you can just start slacking away with your workflow design! Waiting in itself is a topic deserving your full attention as a CRM customizer, since there are more than just one type of waits in the platform we’re working with. Read this great article by Paul Nieuwelaar for an in-depth discussion on the different options available.

There are multiple possible outcomes that should cause our workflow process to wake up. It’s not only the events when a follow-up action should be performed but also any path that leads to a state where the workflow is no longer required. After all, you really don’t want to have an ever increasing number of workflow instances left forever waiting in your CRM system, hogging up resources unnecessarily. So, in our scenario, whenever the status of an opportunity changes to something else than “open” before the reminder date is reached, we’ll want to stop our workflow.

This brings up another best practice regarding Dynamics CRM workflows. We have the option of stopping a workflow with the status values of “Succeeded” or “Cancelled”. As a general rule of thumb, you should always choose to stop your workflow as “Succeeded” unless you have a good reason to do otherwise. This is because a “Cancelled” value is considered an exception in the workflow process job execution and it will leave a permanent record into the system for debugging purposes. If the stopping is just business as usual for your workflow logic, let the system job be deleted by choosing the “Succeeded” option. Only use the “Cancelled” value if you intend to go through and review all the cancelled process instances when testing or debugging your workflows.

Change of date

Since our trigger field is just a normal date field on the opportunity form, we need to take into consideration the fact that a user may at any stage go and update the date value. For example, when the opportunity in question gets delayed due to lack of actions from the customer’s decision makers, the opportunity follow-up reminder would naturally also get postponed to a later date. Whether a reminder has already been sent for the record or not doesn’t actually matter to us, since what we’re dealing with in this scenario is a reusable reminder field that should always work reliably and deliver a notification at the time specified by the user.

Since our start conditions were tied to not just the creation of a new record but also any changes made to the follow-up date field, this will create a new instance of the workflow process whenever the field value is updated. We don’t want to have multiple concurrent waiting workflows for the same record and we most certainly don’t want to send more than one reminder at the follow-up date, so we need a logic to get rid of the old process instance when a new one is created. But how do we tell the existing workflow that a new version has been created? (more…)

April 27, 2014
Synchronization vs. Tracking: Understanding Activity Management Options in Dynamics CRM

Long before a company has any CRM system in place they will already have a bunch of customer facing activities like emails and appointments in the personal mailboxes and calendars of their employees. Once a CRM system is implemented, these activities will not magically disappear but rather they will continue to be a key element in how the customer relationships is managed on a practical, day-to-day level. Typically companies would like to have these communications stored in the CRM database to accumulate a better understanding of both which customers are being contacted by which representatives of the company as well as the detailed information of what’s been said and agreed with the customer in these acts of communication.

Maintaining two separate systems for entering the same information is never an attractive option for information workers who just wish to stay on top of their daily agenda and commitments, without having to worry about keeping multiple calendars in sync manually. Rather than entering an appointment in your own calendar first, then entering the same data into your CRM system for activity tracking purposes, every single user would rather have the ability to promote their selected calendar entries related to customers into their CRM system for meeting the activity reporting requirements expected by their managers. Similarly, instead of copy-pasting information from their inbox onto forms in a CRM system, anyone presented with the option to click one button in their inbox and get the full message tracked into CRM would surely prefer to take this route.

This has been one of the founding principles behind the design of Microsoft’s CRM system since day one. With the market dominance of Microsoft’s activity management related software both on the client (Outlook) and server side (Exchange), making the flow of this data across different systems as seamless as possible can be seen as a low hanging fruit to grab when entering the CRM market with the Dynamics product. Looking back, offering users the possibility of remaining within their familiar and personal Outlook inbox and tracking information into the organization-wide CRM database has been a very compelling user experience at best. Yes, regardless of the countless hours I’ve had to spend solving Outlook related issues during my professional career in CRM, I’m still perfectly willing to admit that this type of UX is definitely worthy of pursuing in a CRM product, because it’s simply how it should work.

How Dynamics CRM actually tracks your data

What most organizations planning to deploy Dynamics CRM often find surprising is that up until CRM 2013 there hasn’t been much functionality on the server side related to managing the flow of activities between different systems. Even though Microsoft owns both Outlook and Exchange, they have decided to build deep hooks only onto the client side of Outlook and not the server side of Exchange. The positive side of this is that you don’t necessarily need an Exchange server for leveraging most of the activity management features of Dynamics CRM. The downside has been that you very much need the CRM Outlook client in place for things to work as you’d expect.

When it comes to sending and receiving email, the CRM Outlook client can act as the component that takes care of all the inbound and outbound emails for CRM. However, for any organization that needs to have emails flowing directly into CRM (such as a customer support email address that feeds items into a CRM support queue) or relies on workflow based email notifications to go out even when the Outlook client of an individual user is not connected to a network, the deployment of the Dynamics CRM Email Router has been in practice a compulsory step to take. Again, this component is independent of Exchange server and can be used also with other email systems via SMTP or POP3 connections. The Email Router can replace some of the email management features of the CRM Outlook client (but not all, we’ll get to that later) and basically “email enable” your Dynamics CRM server, so that it can independently communicate with the outside world via email.

One thing to note is that even customers who’ve chosen CRM Online as their deployment model instead of deploying an on-premises Dynamics CRM server have needed to separately deploy the CRM Email Router if they wish to send/receive email from/to CRM Online without routing all of the messages via the individual Outlook clients of their CRM users. Microsoft doesn’t offer an “Email Router in the cloud”, so you’ll either need to have a local machine available for deploying the router (doesn’t even need to be a Windows Server, also client OS like Vista or Windows 7 are supported) or get a virtual machine from some hosting service, such as Windows Azure. You can leverage the Exchange Online service in your Office 365 subscription for the actual email delivery, but the CRM Email Router cannot be purchased as a service directly from Office 365.

With the latest CRM 2013 release Microsoft has started to address these challenges of dependency on either client machine components (Outlook client) or on-premises servers (Email Router) by introducing a feature called Server-Side Synchronization. This allows the Dynamics CRM server to communicate directly with the Exchange server, effectively replacing the email sending and delivery features of the CRM Email Router. In addition to that, server-side sync can also handle other Exchange items like appointments, tasks and contacts, which can also now flow between the CRM database and the users’ calendars and address books on various devices without any central dependency on a client-side component like the CRM Outlook client.

Great! CRM 2013 server-side sync solves all our problems! End of blog post! Well, not quite. We’re actually just getting to the reason why I’m writing this post, which is the surprising complexity behind understanding the detailed feature sets of the various components that aim to deliver the seamless one-click UX that I was talking about earlier on. Based on what we’ve discussed so far, here’s how the big picture of synchronization methods for CRM 2013 looks like:

As is often the case, the devil is in the details, so let’s proceed with pointing out the “gotchas” that you need to be aware when planning on managing activities in a Dynamics CRM environment. (more…)

March 16, 2014
Power of Choice or the Legacy of Outlook?

The first selling point advertised for Dynamics CRM in almost any context is the user interface familiarity of Office users and the seamless integration to Outlook. Compared to other CRM applications, the feature set available in the Dynamics CRM 2011 client for Outlook is unsurpassed, no doubt about that. However, sometimes you do run into issues that break the illusion that CRM and Outlook would be the one and the same application. Here are a few features that you should be aware of when planning on how you’ll train your users to use the two different client versions available: web and Outlook.

Issue 1: Dashboard ribbons are not context sensitive in Outlook

If you build a dashboard out of grids that present the user with relevant data from various entities, this can significantly cut down their need for jumping between different menus and screens. Say, a customer service representative can easily view all the new items in the email support queue, active cases assigned to him/her and also other open activities. With the help of the context sensitive ribbon the user can then process these records in the same screen, by changing record status from open to closed, accepting items from the queue, creating new tasks etc.

Except, in Outlook that won’t work. The user will only be able to create a new dashboard, but not any of the common tasks, like creating new records for the selected grid. This is because in Outlook the ribbon is not context sensitive within the dashboard. Why is this? It works elsewhere in Outlook, so why not here? I imagine the explanation is that while the normal grids are composed of native MAPI objects inside Outlook, the dashboards are merely web pages as far as the Outlook client can recognize them, so it can’t understand which ribbon should be shown in which part of the page. Bummer.

As a result, if you want to create actionable dashboards that allow users to work on the items presented there, it’s better to instruct them to open CRM through the web client instead of the Outlook client.

Issue 2: Different logic in Quick Find

People who have worked with Dynamics CRM throughout several versions will surely have learned how the Quick Find operates and when you need to use wild cars. With the CRM 2011 Outlook client, this logic no longer holds true. Outlook has its own way of handling search terms, so now we can punch in a search word right from the middle of a field, such as the account name, without entering the asterisk wild card in front of the term.

Great, easier for the user to perform searches, right? Well, it is if you only ever work inside the Outlook client. If you step into the web client views, you’ll discover that things work differently there. Not only do you need to remember to use the wildcard in Quick Find criteria, but there also is a specific Quick Find View. Whereas in the web client the search will cover every active record in the database, no matter from which view you start, in Outlook the search is conducted on the records in the selected view. So, if you’re in the My Contacts view in Outlook client and search for a contact that belongs to another user, the Quick Find results will not deliver any data. In the web client it will.

Also the columns presented in the web client will always be the ones specified in the Quick Find View customizations, but in Outlook the columns will not change as you’re searching from within the current view. However, it appears that the search columns that the Outlook client performs the query on are still affected by the ones defined in the entity Quick Find View, even though this view is never actually presented to the Outlook user. Still following me? If the different search logic is hard for a consultant to remember, just imagine how confusing it can be to the CRM user.

Issue 3: Writing emails from Outlook without Outlook

One of the three core modules in Dynamics CRM is Service. The most typical scenario for utilizing CRM for customer service processes is directing the incoming emails for an address like support@company.com to a queue in CRM. This way the emails are automatically tracked under a contact record if the sender email exists in CRM. Also the queue allows you to see which items are already being worked on by customer service reps.

If you’re working with the Outlook client for Dynamics CRM, then you can write all your emails with the normal Outlook email editor and make use of the rich tools for message formatting, signatures, attaching multiple files with at once etc. Right? Not in this case. If the email you are replying to does not exist inside your Outlook mailbox but rather as an email record inside a CRM view, you can’t send “Outlook” emails as a reply. When you click the reply button, the Outlook client will open the web client email editor form for you.

There’s surely a reason why the email editor in the web client hasn’t been improved since CRM 3.0. Outlook is Microsoft’s premium experience editor that should be used wherever possible, whereas the web editor is a secondary feature. But if you’re using Outlook already, then it would be nice to be able to always remain within that rich client, even when replying to queue emails, wouldn’t it?

Issue 4: Recently used and pinned records behind the File button

Many users will normally be working with a selected few accounts, contacts and opportunities at a time, rather than the whole CRM customer database. This is why the Recently used records menu in CRM 2011 is a great usability enhancement, which is also familiar from many other CRM applications. Right from the CRM main window, from the top left corner where you first look, you’ll be able to open a rich pane that presents all the latest records as well as the views you’ve recently visited.

So, when I’m in the Outlook client then, surely I’m able to access the same list? Well, you are, but you’ll have to open the Office Backstage menu by clicking on the Outlook File menu, then glazing past all the file manipulation options and settings menus, to finally reach the recently viewed CRM records. And even if you reach it, you won’t be able to launch any views from this menu, since again the way how Outlook treats grids is different from the web client. Anyway, you probably won’t be accessing this menu any more often than you tweak your CRM settings, simply because it’s so well hidden away.

Desktop Outlook: how crucial is it still?

Ok, so there are a few quirks to be aware of when jumping between the web client and Outlook client. But how essential is it really to use the Outlook client in the first place? (more…)

November 14, 2011