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. Let's dive in to part two, Sessions.

Sessions

Sessions are an important but tricky aspect of USD configuration design. Crucial Session design concepts—the what, the when, and the why—can be elusive to new learners. Knowing "the how" just isn't good enough, and can cause a lot of trouble. In today's blog, we'll clarify the concept of a Session, how Sessions create separate workspaces, and how USD uses the two different Session types. Finally, we'll build on these concepts to teach the best practice for configuration design as well as showcase the appropriate way to surface customer data in USD.

Let's start from the top. What is a Session? In short, Sessions are for apps and their data. In USD terms, this means Hosted Controls and Data Parameters. In order for USD to run a Hosted Control (sometimes called an "application" or "Window"), a Session must first exist in order to contain it. Once a Session is populated with Controls, those Controls may expose data in USD's Data Parameters. This is how separate Controls use the USD framework to communicate with one another. Sessions come in two options, Normal and Global. The distinction is vital to configuration design, so let's explore their differences.

Normal Sessions are shown at the top of the USD window as a layer of tabs. Many Hosted Controls will already appear in the main area of the window as tabbed applications, so whenever USD has at least one Normal Session, it inserts the layer of larger Session tabs above the application tabs. This allows Agents to easily distinguish between their tabbed Session workspaces. Additionally, USD maintains "privacy" between these Sessions. This means that multiple Normal Sessions are always unaware of each other, so customer data cannot "bleed into" any other Session where it does not belong.

The Global Session is different in a number of very important ways. From a practical perspective, a Normal Session is for doing work, while the Global Session is for finding work, waiting for work (like the next phone call), or both. There is always only one Global Session, and it opens and closes with the USD Client. When configuring Hosted Controls, it's important to consider which type of Session will serve as the container for the Control. Global Hosted Controls can only run in the Global Session, while non-Global Controls (or Session Controls) can only run in a Normal Session.

In a typical configuration, the USD Client will start up with the Global Session only. This means that the agent will see no Session tabs, only Global Hosted Controls, until a Normal Session is created. On the start of a Normal Session, Global Controls do not hide themselves. This is another important aspect of the Global Session: It is everywhere, all the time. Global Controls do not hide themselves simply because a Normal Session exists. Because they are always accessible, Global Controls enable USD's multi-session functionality. Generally speaking, Controls that search for customer records should be Global, and should start a Normal Session when opening a located record.

That covers Global Controls, but what about Global Data Parameters? Sessions are for Controls and Data Parameters, and Global Controls never hide, so do Global Data Parameters ever hide? Actually, no. They don't, and that bring us to our best practice recommendation: never surface customer data globally.

Sure, multiple normal Sessions cannot see each other, but they can all see the Global Session and all of the Global Data Parameters. While data in a Normal Session cannot "bleed into" another Normal Session, separating global customer data from Session customer data is a design challenge well worth avoiding.

From a technical perspective, it may be possible to create a configuration that distinguishes between Global and Session data, one that micromanages global data parameters so that normal Sessions are never confused about their information source. From a practical perspective, don't reinvent the wheel. Normal Sessions already do this perfectly! Whenever a Global Control touches a customer record, you should immediately send that record to a non-Global Control in a new normal Session.

When planning your production environment's USD configuration, be sure to place special emphasis on your Session design. USD works best with configurations that are designed to create Sessions for one reason and one reason only: customer data.

That's all for the today's installment of USD and the CSR. If you haven't already, check out last week's installment, USD and the CSR: Part One – Controls.

Happy CRM'ing!