Keys and Dynamics CRM 2015 Online - Update 1

Recently, Microsoft released Update 1 to its online subscribers.  This included a number of features and enhancements, and one I wanted to talk about today is Keys. I read through the release notes and somehow completely missed this feature as did many people in the CRM world that I work with, so I figured that making a post on the topic wasn't a bad thing.

So, keys.  When I first heard the term I thought back to my database days and thought that it would be related to records being unique...but CRM already had the duplicate detection engine so in my mind it had to be something else.  After some digging and playing with the new feature though, CRM Keys exactly what I thought:  Unique values on an entity.  It can be based off one attribute or multiple (compound keys for the SQL readers out there).  So if you start using Keys, you don't have to re-implement that plugin enforcing unique-SSNs requirement for the 10th time.  So how do we do this?

First, open up a solution or click on Customize the System.  Pick an entity in your solution, and you'll see a new Keys option:

Inside that setting, you create a new key, give it a unique name like you were creating a new attribute, then select which attributes on the entity should be involved in the Key [I removed my entity prefix from the screenshots]:

And that's all there is to it!  Test it out, and you'll get a message similar to the following when you try to create a duplicate record according to the new Key you just created...and you'll notice that it's blazing fast:

But the question remains, how does this work?  What's it actually doing?  Well, if you try to create a key that would be invalid (say, unique on first name), you get a message similar to the following:

As you can see, the name of the actual database key that the system is trying to create is displayed...ndx_for_entitykey_<keyname>.  So at the end of the day, these new CRM Keys really are just database keys/indexes.

One thing I'd like to get around to playing with is are these actual keys?  Can these be utilized not only for making sure records are unique, but also to create database keys on tables to speed up processing?  Hopefully I'll get to that in the future, and when I do I'll post my findings here.

Happy keying!

Microsoft Unified Service Desk (USD) Configuration 102 - Non-Entity Information

In this next installment of an introduction to configuring USD, I'll go through some elements that aren't entities used in configuring but are still critical in knowing how to use USD to it's fullest. Below are the items that'll be discussed:

• Sessions
• Replacement Parameters
• Debugger

Sessions

One of the benefits of USD is that you can have multiple groups of hosted controls open at the same time.  A session is a set of forms and data related to one thing; that 'thing' usually being an account or a contact.  For instance, in a call center environment you can have someone in multiple chat sessions at the same time.  Each session in USD would be related to one of those chat sessions.  This way you can have multiple customers' forms open at the same time, and also any CRM forms related to those specific callers without losing track of what's related to what.

Replacement Parameters

Replacement parameters are used to store session-based information within USD hosted controls. In programming terms, think of them as key/value pairs.  These are used to pass information between CRM, any systems that you're integrating with USD, and any custom USD components.  These values can be based off a specific session or be global.

For example, you can make a custom search page that'll search an external system and return social security numbers.  From there you can search CRM for that social security number and start a session around that specific customer.  To pass that information around, you would use replacement parameters.  Additionally, once the CRM form for that customer is open, you can also pass information from the search page into that form using replacement parameters (use the Event of BrowserDocumentComplete to call an Action that will read Replacement Parameters).

To access replacement parameters use two leading brackets and 2 trailing brackets in your code.  For instance, [[Contact.FullName]] would be replaced in USD by a contact's full name.When accessing replacement parameters, there are many trailing parameters that can be used.  Some of the more common ones (from my experience) are:

• g - Global.  If a value is global, put a 'g' after the first ending bracket.  Ex:  [[SearchControl.SSN]g].
• + - Optional.  If the value doesn't exist, the action calls and other code will continue running.  Otherwise the action call will fail and any sub action calls won't be fired (that this could be a desired result!).  For instance, [[SearchControl.MiddleName]+].
• u - URL Encoding will be used when retrieving the value.  so a space would be replaced by "%20".

Additional Replacement Parameter parameters can be found on the MSDN site:

http://msdn.microsoft.com/en-us/library/dn864934.aspx

Debugger

The debugger is used to see what's going on in the background of USD, and also manually fire off action calls and events for testing.  There are many pages to the debugger, depending on what you're looking for.  Personally, I use it for three main purposes:

• Viewing Replacement Parameters
• Viewing Events/Action Calls
• Manually firing off events and action calls.

To view the replacement parameters, click on the Data Parameters tab in the debugger:

Here you can see all the replacement parameters for the given session and also any global values. Additionally you can use the Copy button on top to get the code needed to access that specific replacement parameter through code or USD configuration.

The action calls that have been run since USD has started up will be displayed under Action Calls.

As you can see above, everything has been captured from events firing, hosted controls closing, even the opening of the debugger itself (the last line above).

Additionally, you can manually run actions:

First, click on the dropdown arrow to bring up additional debugging options.  Once you do that, you'll see the 2nd image above where you can pick a specific action call to fire.  If you'd like to enter data into a specific action, click on Direct Action and from there you can pick which Hosted Control you want to use along with which specific Action you want to fire.  You can also use this to 'hide' certain actions from users and use them for debugging and development purposes.  For instance you might be pulling information from another application but never actually visually display that system.  If you're suddenly having troubles pulling data from that system, you can add an action to make that application visible.

Tips and Tricks (And hidden, lesser known items)

USD can be cached.  Every time USD opens, many many records are pulled down from CRM.  You can set USD to use caching though though Options (Options will be gone over in my next post).  If you have an Option named 'ClientCacheVersionNumber', the USD client will NOT pull all information from the server every time a user connects.  The only time all USD data will be retrieved is when this Option's value changes, making the locally stored value different from what's on the server.  If this option doesn't exist, the client will always pull all USD information down from the server.  I recommend that once you're in production you use this option, and even in your development environment to speed up actual development.

If you want to turn off the caching mentioned above for specific users (say you as a programmer always want the values loaded from CRM and not cached), you can do that through User Settings.  They'll be covered in the next section, but they're basically options on a per-user basis.  That said, just create a new User Setting record, set the Name to DisableCaching, the User field to the individual that you don't want to use caching, and you're all set.

You can fire USD Events from within CRM itself.  Let's say you have multiple values stored in replacement parameters and want to use different ones based off dropdown values changing on a CRM form.  If you want to pull specific values, you'd have to use an Action Call, but how do you fire them?  You'd first have to make a custom hosted control to accept a DoAction call (I'll cover this in a future post, but for now you can check out the MSDN site on making a custom control).  Then, you can call the DoAction event from a specific hosted control by calling http://uii/<hostedcontrol>/<actioncallname>.  USD will intercept that call and instead of displaying a webpage, it'll fire a DoAction event and pass in the given action.

------------

Next time I'll finish what the first USD post started by finishing the review of the entities that are involved in configuring USD.

Microsoft Unified Service Desk (USD) Configuration 103 - Other Entities

In our 3rd post around configuring CRM, I'll go over the rest of the entities involved in setting up and using USD.  This post will be a great starting point and also a good reference point to definitions of some USD records that aren't used very often, but are important nonetheless.  Personally, I'd bookmark it and come back to it to remind yourself what each thing is used for and what configurations are possible out of the box.  Before actually getting your hands dirty with USD, a lot of these entities might seem pointless/useless, but that'll change over time as you get used to USD and want to configure more advanced features.  That said, let's get to work.

The entities we'll cover today:

• Option
• Window Navigation Rule
• Entity Search
• Entity Type
• Configuration
• User Setting
• Scriptlet
• Additional Agent Script Components

Additional USD Entities

Options - Key/value pairs for use with USD.  Say you have use a web service to pull some data from another internal application that you're hosting.  In your development environment, you connect to the development web service.  In production, you connect to the production web service.  You can easily change where your USD components connect to using Options.

Window Navigation Rules - Determine how USD will handle moving from one hosted control to another.  For instance if you're on an Account page and click on a phone call record in a sub-grid, what happens?  Does the phone call record open up right in that tab?  Does a new tab open?  Does the phone call record open outside USD?  This is determined by the Window Navigation Rules.

Entity Searches - Contain FetchXML and are used in conjunction with Window Navigation Rules. You can use replacement parameters here (we'll get to those shortly) so the Fetch is dynamic.

Entity Types - Used as a link between USD records and entities themselves.  A lot of records, Entity Searches for instance, need to be related to an entity.  Entity Types are these relationships.

Configurations - Used to limit what USD records are loaded per user.  This way you can easily have the USD application look and work differently for different user roles.  For instance, you can create a toolbar button to email a contact.  Maybe you only want that button visible to supervisors.  This way you can create the appropriate USD records and only have them visible to supervisors by assigning a Supervisor configuration, while users on the phones would have a Basic User configuration.

User Settings - Used to set values on a per-user basis.  They're just like Options, but are set per user.

Scriptlets - JavaScript to be used in a USD setting.  Their main use over the usual CRM web resources is to utilize replacement parameters.

Agent Script Components

In my first USD Entity post I touched on agent scripting, here I'll go into more details.  When you create agent scripting, it's separated into three components:

• Agent Script Task
• Agent Script Category
• Agent Script Answer

Agent Script Task - These were talked about in the last post; they're the main steps in the scripts. Each script contains two pieces: Text and Instructions.  The Text contains what the user should say to the person they're interacting with and the instructions are notes to the user stating what they should do.  To go from one task to another, Agent Script Answers are used.

Agent Script Answers - These are answers to script tasks that can lead the user down different paths through the application.  For example, in the case of a phone call the user will need to do vastly different things based off why the person on the phone is calling in.  If the caller has an issue with a product, the user can click a button to open a Case.  If they have a quick question that can be answered easily, another answer can bring up FAQs for the user to look through.  If the caller wants to talk to a supervisor, another button can route the call.

Agent Script Task Category - These are used to group Agent Scripts records together to make them easier to find.  It's not actually used by the USD client at all.

Using all of the entities covered in this post and my 101 post, you can create a very rich experience for your USD users.  The out of the box example from Microsoft is just this.  There's no custom code, no DLLs to install, nothing 'special' that was added to make all of that work.  If you do want to create custom components, it's definitely an available option and something I'll be covering in the future.

And as always, if you have any questions about what I've covered today, let me know!