USD and the CSR: Part Three - Rules

When it comes to mastering Unified Service Desk (USD), it's important to remember CSR. CSR stands for Control-Session-Rule and is an approach to the most effective way to learn USD. In system design, quality relies on the vision and expertise of the team. To gain these strengths as your team learns USD, the best approach is CSR.

USD is new technology, which means there's a lot to learn, so learn Controls, Sessions, and Rules one by one with the help of this three-part blog series. With all of this knowledge under your belt, you'll be in a much better position to begin designing the USD configuration that will improve efficiencies and drive down costs in your Customer Care environment. If you haven't already, get caught up with Part One – Controls and Part Two – Sessions.


Without a doubt, the most difficult USD configuration concept with which new learners struggle with is the Window Navigation Rule. What's a Window, what's a Navigation, and what's a Rule anyhow? Let's break it down.

In USD, all Controls are applications (or "Windows") that can perform or generate Navigations. With that out of the way, we're past the tricky part! The rest is common, everyday vocabulary. In computing, navigation describes the act of virtual traversal that provides a user with access to some digital resource. Rules are also an intuitive concept because, as we all know, they should never be broken. Now, to bring it all together: Window Navigation Rules are the Rules that define how USD should handle Navigations within or between various Windows (or Controls). Let's take a closer look at how they actually work.

Rules have three essential elements: Source, Destination, and the Object of the Navigation itself (Entities or URLs). To what resource, record, or URL am I navigating? What Control created the navigation and what Control should render it? Furthermore, when a Rule is successfully applied, should any Action Calls execute?


Generally, this is easy to define. "Never show a Contact Form in the Account Control," for example. "Instead, always route Contact entities from the Account Control to the Contact Control." This may sound like an easy Rule to write, however, confusion commonly sets in when a beginner attempts to define a Rule's Route Types and Actions. With four possible Route Types and six possible Actions, it can be frustrating to determine how to mix and match them successfully. Let's trim things down a bit by eliminating the less useful options here.

The two most applicable Route types are Popup and In Place. Anyone with web browser experience can quickly understand these. When using IE (Internet Explorer), if a navigation would take you away from the current page and to a new page in the same tab, then USD will recognize this navigation as In Place. However, if IE would retain the page that you were on and instead load the new page in a new window or new tab, then this is a Popup Route Type, in USD terms.


Even with such clarity here, writing Rules often calls for a bit of persistence and sometimes even guesswork. For example, let's say you have a CRM View like My Active Contacts. In IE, clicking a Contact on this View will navigate away from the View, taking you to the Form for the selected Contact without generating a new browser tab. This sounds like an In Place navigation, right? Yes, it is, however, USD may beg to differ. In this situation, modifying the Rule to handle the Popup Route Type will often cause it to work, even though the navigation in question is clearly In Place.

This may sound tricky, but it's just a simple gotcha. If your Rule is not effective the first time you test it, try changing the Route Type from Popup to In Place, or vice versa. After a few encounters with this gotcha, you may ask yourself, "Why aren't I just writing Rules for both Route Types in the first place?" Great question, and yes, we agree! Typically, your need for a Rule can be defined by Source, Object, and Destination as a trio, with no consideration for Route Type. If you need all Contacts that Popup from the Account Control to show in the Contact control, spend an extra moment to ensure that In Place navigations from Account to Contact are handled the same way. Also, keep in mind that the UII Actions New_CRM_Page and Open_CRM_Page always result in Popup navigations, where the executing Control is the source of the navigation.

You will seldom use the Route Types OnLoad and Menu Chosen. Chances are, you are hiding the CRM Navigation bar, thereby preventing Menu Chosen navigations in the first place. OnLoad Rules are frequently redundant, so you can avoid these as well. Another Rule or Action Call already handled some navigation (the load itself), so automation should be implemented on that first Rule or Action Call rather than on a separate OnLoad Rule.

Now that you understand Route Types, what Action should USD take when such a navigation occurs? In some circumstances, you may use None to deny a navigation or Show Outside to navigate using a browser outside of USD. Mostly, your Rules will use specify Route Window or Create Session. These Actions both perform the same type of simple window routing, the only difference being whether or not a new Session is created.


Rules like this are largely responsible for enforcing your Session design. Remember the best practice we discussed from the part 2 blog on Sessions? It states, "Never surface customer data Globally." This is best maintained by having a carefully-planned series of Rules that handle Popup and In Place navigations by performing Route Window or Create Session Actions.

That's all there is to it! As you analyze the pages you're surfacing in USD, use these tips to write the Rules that will keep your agents focused and effective. Once you have a good understanding of how Rules can enforce your Session design, consider boosting your configuration's performance using Microsoft's background fetch technique. Using this design pattern, Rule destinations can leverage USD entity searches to quickly retrieve the more important field data for context-sensitive Controls, while heavier CRM pages load in the foreground.

That's all for this blog series on USD and the CSR. And remember, if you haven't already, check out USD and the CSR: Part One – Controls and USD and the CSR: Part Two – Sessions.

Happy CRM'ing!

Let's Hear it for Rules Based Record Creation

Did you know that you can create or update multiple records at one time, using automated rules? Today's blog will tell you more about this handy feature and how to make it work for you!

This feature allows users to use multiple activity types (Appointment, Email, Phone call, Task, Service and Custom activities) to create or update records automatically. Rules can create multiple CRM records from one activity type and increase the efficiency of automatic record creation. Automatic record creation or update, eliminates the need of manually writing any code. Nice, right?!

While creating a rule, you need to define the conditions to create or update records into the system. You can also define post record creation or update actions. To enable the rule to update records, you must add an update step to the rule. You can collect additional information for the activity record by defining some channel properties while creating a rule. This requires a use of JSON parameter attribute from activity.

Once all rule creation/configuration is done, you will need to activate the rule which creates an out of the box workflow. The rule is able to read the incoming source activity data and to create or update records into the CRM system for Dynamics 365.

Similarly to all other CRM components or Web resources, rules can be added to the CRM solution and can be exported and imported to other Dynamics 365 organizations.

Steps to create and activate a rule:

Note: You need to have the customer service, sales manager, marketing manager or equivalent permissions to create and activate rules.

-Login to CRM and navigate to the Settings tab.

- Select either the Service Management or Business Management option.

- Click Automatic Record Creation and Update Rules.

Rules Based Record Creation

- To create a record creation and update rule, click New.


- Type or modify information in the fields.

Ex: Name, Source Type, Queue etc.


- Click Save.

- Under "Channel Properties," in the Additional Properties box, click a channel property group.

Rules Based Record Creation

- Under the "Specify Record Creation and Update Details" section, click + to define the conditions for creating or updating a record and specify the properties of the record.

Rules Based Record Creation

In the "Conditions" section, select the record, channel properties, fields, and relational query operators to specify when a target record should be created or updated.

- Click Save and Close

- Activate a newly created rule to put it into effect


CRM Tip!
After the rule is activated, the only way to change the rule is to first deactivate it. Open the rule, and on the command bar, click the Deactivate option and viola - you are good to go!

To stay on top of all things Microsoft Dynamics 365, check out our daily blog and signup for our CRM Newsletter.

Happy CRM'ing!