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.

Rules

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!