New in CRM Online Spring ‘14 / Service Pack 1 / Leo: Case Hierarchies

The Spring 2013 / SP1 / Leo release for Microsoft Dynamics CRM 2013 gives us the ability to link multiple Cases under a Parent Case..  Here’s exactly what you get:

Configurable Options

System-wide options can be configured under: Settings –> Service Management –> Parent and Child case settings

You can opt to have fields map down from the Parent when you add a new Child Case:

image

And you can determine how Case Closure should be controlled / automated:

image

Adding a New Child Case to an Existing Case

From the Case form a Command Bar now provides a means of adding a Child Case:

image

This pops the Quick Create Case form, with fields auto-populated based on the inheritance rules you configured:

image

Clicking Ok generates the Child Case, closes the Quick Create form and returns you to the Parent Case.  You can see the Child Case listed in a new sub-grid on the form:

image 

Now, if your Parent Case is already a Child Case of another Parent you won’t be able to do any of this.  Grandparent relationships are not yet supported.   If you are not seeing the “Create Child Case” button that will be why.

I tried disabling the Case entity for Quick Create to see if the “Create Child Case” button could pop the the ‘full’ Case form.   This didn’t seem to work, things just spun.  I expect this is a quirk of the pre-release software I am using.

I also tried adding a Child Case via the Sub-Grid rather than the Command Bar button and found that does the same thing as the button.

Parenting an Existing Case to another Case

You can also pick up an existing Case and then Parent it.  You just need to populate the lookup field on the Child Case.  This works fine.  In this scenario, the inheritance does not fire though (which make sense).  So, it is a similar experience to what we know with mapping rules on relationships.

Closing a Case

The process for resolving a Case remains unchanged.  If you configured Child Cases to auto-close they seamlessly close in background without notification.   If you configure it so that the Child Cases must be closed before the Parent can be you will get a helpful error when you try to break that rule:

image

Bulk Associate Cases to a Parent

One last feature. Say you have a bunch of Cases reported from Customers that all relate to the same issue.  You might like to link those all under the first reported Case for that Issue to drive your reporting.   From the Case view you can do this by bulk-selecting your Cases and clicking the “Associate Child Cases” button:

image

You need to select not only the Child Cases but also the one you want to be the Parent.   You will be prompted to identify the Parent:

image

And CRM pops a little confirmation dialog to let you know its all done:

image

Parent–Child Case Views and Attributes

To support parent-child relationships there is obviously a new “Parent Case” lookup field on the Case entity.   Microsoft has also kindly provided a “Child Cases” field that gives you the count of Child Cases attached to a Parent.   This was a nice surprise to see. 

You will also see a couple of new System Views that isolate Cases that are either Child Cases or Parent Cases (filtering on Cases that have one of these two fields populated):

image

Ok, what have I missed?  Please share anything via the Comments and I’ll add into this Post.

HTH

Advertisements

What’s New in the Spring ‘14 Release / Service Pack 1

The “Leo” release for Microsoft Dynamics CRM 2013 has just been released and there is some new functionality to learn.   If you are CRM Online customer the release is known as “Microsoft Dynamics CRM Online Spring ‘14”.  If you are a CRM On Premise customer it is simply being called “Service Pack 1” (SP1). 

Whatever you want to call it, here’s what you get!

Customer Service Enhancements

Case Hierarchies

  • The ability to associate Cases under a Parent Case.    
  • Fields can be configured to auto map down.
  • Case closure can be configured to cascade down or be prevented until all Child Cases are closed.
      • One level of hierarchy only
        • Maximum of 100 child Cases
  • Read more…

Case Merging

  • The ability to merge 2 or more Cases
  • Duplicates are canceled, child records are re-parented
    • Can merge up to 10 at a time through the UI
    • Can merge only 2 at a time via SDK

Entitlements

  • Next evolution of Service Contracts (pre-purchased Incidents or Hours, decremented automatically)
  • Ability to define multiple Entitlements per Customer
  • Can specify Entitlements per Channel
  • Can associate Contacts and Products
  • Read more…

Service Level Agreements (SLAs)

  • Define “First Response”, “Case Resolution” and “Follow Up” SLAs
  • Define Warning timing and Failure deadlines
  • Define automated actions to occur at Warning and Failure points
  • Define customer service schedules (e.g. 9 to 5 PST, Mon to Fri) and business holidays for business hours based SLAs
  • Uses Workflow engine for execution
  • New “Timer Control” can be added to CRM forms to communicate Target SLA to user, with red, amber, green alerting.
  • Read more…

Queue Enhancements

  • Private Queues, where you get to dictate who can see which queues
  • Improved filtering of the Queues lists, so the default queues for each User, Team and BU appear less commonly
  • New calculated field on the Queue record indicating the count of items in the Queue (to assist with load balancing)
  • More intuitive buttons for end users when interacting with queue items

Case Routing Rules

  • Define rules that will route new Cases automatically to Users, Teams or Queues
  • Triggered automatically and able  to be run manually

Email to Case

  • Configurable rules for automatically generating Cases from inbound Emails as they hit CRM (via Email Router or Server Side Sync)
  • Chose when the rule should apply and how the Case fields should be defaulted
  • Can be associate to an Email Queue
  • Smarts to handle automatic Contact creation (when applicable)
  • Smarts to associate follow up emails to an Existing active Case
  • Auto-responder logic using email templates

Status Reason Transitions

  • The ability to define for each Status Reason value a constrained list of ‘Next’ Status Reasons
  • Case and custom entities only

Misc. Enhancements

Social Profiles and Social Activities

  • New entities added to the data model
  • Added to support integrations with social applications (not yet enabled for end users)

Target CRM Version

  • When exporting a Solution you can select the target version of CRM you wish to support and CRM will remove any offending items that would prevent a successful import

Command Bar Display

  • The number of buttons that will display on the form has been increased from 5 to 7

Workflow Conditions

  • You can now use the familiar “And” and “Or” groups that you are used to from Advanced Find when defining Conditions in your Workflow rules

Real-time Duplicate Detection

  • The return of the feature that we used to have in CRM 2011 (even with the same confusing UI)

Lync Presence

  • Now available in Lookup fields and Activity Feeds

New SharePoint Integration Architecture

  • New for integration scenarios between (only) CRM Online and SharePoint Online
  • Documents are represented as Document records in CRM (new entity) and the SharePoint iframe is replaced by a Documents sub-grid

Sandbox Environments for CRM Online

  • Provisioning tool for creating Sandbox environments by copying a production CRM Online instance
  • Supports ‘Minimal Copy’ (schema and customizations only) or ‘Full Copy’ (everything)
  • Ability to reset and snapshot

New Compatibility

Added support for:

  • Windows 8.1
  • Internet Explorer 11
  • iOS7 Safari on iPad (web application)
  • iPad Air using Safari (web application)
  • Windows Server 2012 R2 (CRM server)
  • iPad Air using CRM for Tablets

Insights

  • Native integration to Insideview (CRM Online only) for real-time industry information on Contacts and Organizations
  • Read more…

Tablet Client

  • Cases now editable on the Tablet
  • Added support for Android Tablets
  • Can now sign out as one user and sign in as another
  • Can now reconfigure the App to point to another CRM Organization without having to reinstall
  • New Windows 8.1 App (provides the cached offline experience for CRM On Premise customers that was previously not available)

New Products!

And the Spring release schedule also sees the release of the below companion applications:

  • Microsoft Dynamics Marketing (the acquired product “Marketing Pilot”, now absorbed into the Microsoft CRM suite and available for an additional license fee)
  • Microsoft Social Listening (the acquired product “NetBreeze”, now absorbed into the Microsoft CRM suite and available for an additional license fee)
  • Unified Service Desktop (USD) (the latest evolution of the Customer Care Accelerator, releasing fully later in the year)

CRM 2013 New Features: Using Real-time Workflow for Validation Rules

Real-time workflows are a new feature in CRM 2013.  When I train on these the learning curve tends to be a gentle slope, the simple message is “you can now configure your workflows to run synchronously”.   Those 9 words comprise 90% of what you need to know.  That’s not to say this isn’t an awesome feature, its just easy to understand.   Here are a few other things you should know and cool new usage scenario that you should consider…

 

Execution Context

Workflows (both asynchronous and real-time types) can now execute either in the context of the User or in the context of the Owner of the Workflow:

image

If you define the workflow to execute as the owner of the workflow than the workflow can potentially perform actions the user does not have permission to – e.g. create certain records, or delete a record.   The workflow will have the permissions of the Owner of the workflow rule which you can set higher than the permissions of the end users.

If you define the workflow to execute in the context of the user then any records created or updated will reflect the user as the CreatedBy / ModifiedBy.

 

Validation Rules

I’ve had scenarios in the past where I have needed to perform a validation when a user attempts to update or delete a record.  If the record in question has certain properties I would need to reject the user action.  A common example is where you have external data that is synchronized with CRM and you need to prevent updates to those synchronized records, but not other records that are user-created – and these records reside in the same entity.

In CRM 2011 I either did this via JavaScript or a pre-update/pre-delete Plug-in.   A plug-in is more robust solution as it would fire regardless of how the update/delete was initiated.    No, we can do this via a real-time workflow!   Here’s how…

In my system I have Account records that are either user-created or created externally from CRM and synchronized with CRM via an integration.  I have an “Account Source” field which distinguishes between these two:

  image

My users should be able to delete Accounts that are flagged as “User-entered” but not those flagged as “Integration”.   I can’t achieve this via the CRM Security Model as it does not support data-based access rules.   I need to grant my users delete permissions and then overwrite their delete attempts when I need to block that action.  I can do this with a Workflow process.

Here’s the properties of my Workflow rule:

image

Note I have configured this as a real time workflow:

image

And I am triggering the Workflow to run Before the record is deleted:

image

Here’s the conditions and actions:

image

A simple condition that checks the value of the Account Source field.  If the value is “Integration” then the proceeding Action fires.   The Action is to Stop the Workflow with a status of Canceled.   Stopping the Workflow has always been an available Action:

image

But with workflows not able to run synchronously we can use this feature to block the user action that triggered the Workflow in the first place.

When you add this Action to a Workflow there are 2 options to pick from.  You either stop the Workflow as Succeeded or as Canceled: 

image

We need to stop the Workflow as Canceled in this scenario as that will block the delete from completing.

Next to this dropdown box is a Set Properties button.  If you click that you can add an Exception message that will pop to the user to explain why you have blocked their action:

image

You can embed fields from the record or from related records just like you can when you are using workflow to create a record.   In my case I just include some static text. 

Here’s the workflow in action.   I select an Account with an Account Source value of “Integration” and click Delete:

image 

I click through a couple of standard CRM warnings:

image

And then the workflow kicks in and throws the exception that I configured:

image

And my record remains:

image

Let’s look now and how this type of validation approach works in an Update scenario.   I tweak my workflow to run on Update instead:

image

And I adjust the error message:

image

Let’s test this out…

I set the workflow to fire when the Account name changes.   Let’s change that and a couple of other fields too:

image

And then wait for the auto-save to fire.   What you will see is a Business Process Error notification down in the Save section of the form:

image

Clicking on that will reveal the error:

image

Trying to force the save or navigating away from the record also results in the error popping.

The nice thing here is you don’t lose your changes when you hit this error.  You can’t save until you address the issue and none of the updated fields get updated.   But if I remove the change from the Account Name I can then save successfully and the other fields that I was also editing get updated successfully.

Hope this helps someone.

Modifying Entity Icons the Quick Way in Microsoft CRM

Need to apply a bunch of icons to your custom entities in Microsoft CRM?  Here’s a shortcut for you, using the awesome XRM Toolbox…

First, get your hands on the XRM Toolbox (which now supports CRM 2013 as well).

Next, boot it up and click the Connect to CRM button:

image

(note: if you don’t see the apps listed on the home screen like they are in the screenshot above you will need to go back to the program folder and right-click on each DLL and unblock each file).

Ok, so first step is to upload some icons. 

Here, I typically pinch from Microsoft.  I go to an on premise installation of CRM and rob the image files from the crmweb folder.   Here’s some of the icons from my CRM 2013 server:

(from:  C:\Program Files\Microsoft Dynamics CRM\CRMWeb\_imgs\Ribbon)

image

To get these into CRM as Web Resources I use the XRM Toolbox’s Web Resources Manager:

image

I go to the File menu and select Load Web resources:

image

I browse to my folder and my files appear:

image

(I’ve pre-selected some that I want prior to this step and renamed them to match my entities)

Last step for these icons is to select the files I want and then from the CRM menu select the “Update, publish and add to solution” option:

image

Cool, that’s all my Web Resources created. Now, to apply them to my custom entities I launch XRM Toolbox’s ICONATOR !!!

image

This is another simple to use app.  You click the Load button:

image

And then its just a case of joining the dots.  Select your entity, select the icon you want and then click Map.  Do this once for the 16×16 image and then again for the 32×32 icon.  Repeat for each entity:

image

And then finally click Apply and Publish:

image 

This is pretty quick stuff. XRM Toolbox is a great tool. 

🙂

Dynamically Disable Ribbon Buttons in Dynamics CRM

Today I had to dynamically disable a custom Ribbon button.  My rule needed to be based on fields on the form and based on the form mode.  I only want the button enabled on the Update form and only when a certain checkbox is checked.

Here’s the steps.  These will work for CRM 2011 Ribbon buttons or CRM 2012 Command Bar buttons.

To modify the CRM Ribbon / Command Bar I use the excellent Ribbon Workbench tool from Develop 1.  To use this tool download their solution file, import it into CRM and then open the Solution.  The Ribbon Workbench UI will launch.  You will be prompted to open a solution.   For best performance it pays to create a temporary solution that contains just the entity you wish to customize and the JavaScript web resources you need to refer to (if applicable).

Here’s my custom Ribbon buttons as seen in Ribbon Workbench:

image

You add custom ribbon buttons by dragging a “Button” from the Toolbox in the bottom left corner of the screen up into the ribbon.   Then you set the Button properties through the Property window on the right and define the Button’s Command through the Solution Elements tab in the bottom middle of the screen.

Back to our dynamic rule.  First step is to define an Enable Rule.  This is done from the Solution Elements tab.  Right-click on Enable Rules and select Add New:

image

Click the arrow to expand Expand Rules, you will see a new Rule listed:

image

Right-click on the Rule and select Add Rule:

image

Up will pop a bunch of Rule types for you to pick from.  You can chose options here if you want your Button to be enabled only for certain form modes, or in say the Outlook Client but not the Web Client.   In my case I want to control the state of my button based on the results of a JavaScript function so I’m going to choose “Custom Javascript Rule”:

image

Next, click on the CustomRule and then complete the Properties on the right.  The important properties here are the Java Script Web Resource library (which will need to be contained in the Solution file you selected when Ribbon Workbench launched) and the FunctionName:

image

So, obviously, those properties need to match to an actual JavaScript function you have loaded into CRM via a Web Resource.  Here’s mine:

image

The JavaScript function can execute any logic you like, it just needs to return true or false.  A value of true will result in the Enabling of the button, false will Disable it.

One last bit, we need to add the Enable Rule to the Command tied to the Button.   This is also done from the Solution Elements tab.  I already had a Command defined so I just right-click on it and select Edit Enable Rules:

image

Up pops a Rule selector, simply select your rule and push it over to the right via the Add > button:

image

If you didn’t have a Command defined for your Button you would need to right-click on Commands in the Solution Elements tab and select Add New and then add the Enable Rule.  And you would need to select the Command you created back in the Button’s properties.

Last step is to Publish the changes:

image

And that’s it.  The approach for dynamically changing the display state of a button is almost identical so you are not an expert in that too.

Happy ribboning.

Oh and yes this is all the same in CRM 2013:

image

CRM 2013 New Features: Access Teams

The latest release of Microsoft Dynamics CRM comes with a new security model approach for us to consider.  The new “Access Teams” functionality in CRM 2013 suits scenarios where data access rules cannot be easily determined upfront but rather need to be set ‘on the fly’ on a record by record basis.  The common example is where an organization assembles a unique group on individuals for each sales pursuit or to manage each customer.

In this post I will explain the advantages of this new approach over the old approaches we had in CRM 2011 and I will demonstrate how to configure Access Teams.  But first let me show you what this looks like…

Once Access Teams are configured for an entity, you will have a sub-grid on your CRM form from which you can simply pick and choose who to grant access to:

image

And that’s it, that’s all you need to do as an end user.   Whoever  you select will immediately be granted access to the record and (potentially) to its child records.

How is this achieved?  Well, behind the scenes as soon as you add someone via this sub-grid CRM will create an Access Team, add the user to the Team and then share the record to the Team.  

So there is not a lot of new magic here, this is just Team-sharing automation, but now available out of the box.   

Do note though, these new Access Teams are treated a little differently from the traditional Teams we know and love in CRM.  They are stored in the same entity but CRM treats them differently to optimize performance (note: CRM filter Access Teams out of views by default, you have to use Advanced find to see them, they will stand out when you do see them as they are named with a GUID).  Traditional record-owning Teams are cached by CRM and when you have users belonging to a large number of Teams you can suffer from performance problems.  These new Access Teams are not cached and that avoids this performance limitation.   However, because behind the scenes this functionality is using Sharing you are vulnerable to the performance issues associated with blowing out the Principal Object Access (POA) table.  Make sure you read this whitepaper a few times.  You also need to consider child records and whether the share will cascade or not (more detail here).  Not cascading will result in records not being visible, cascading will result in more POA records. 

Alternative Approaches

Users can create a Team, add members to the Team and assign the Team as the owner of the record.  Setting this up each time is a clunky user experience.  You lose the distinction of a primary owner and this will result in poor performance once a user belongs to too many teams.  On the plus side there is minimal POA impact.  Do consider though, do you still want a specific individual identified as the Owner of the record (perhaps with additional permissions) or is it ok to just have a Team specified?   You could always put a custom User lookup field on the form if calling out an individual owner was important.

Alternatively, you could stick with one record owner and have users manually Share to grant permissions out to individuals.  Again the user experience with setting this up each time is clunky and with this approach you can also hit performance problems if dealing with larger volumes due to the number of sharing records generated in the POA table. 

Setting up Access Teams

The configuration of Access Teams requires a little ‘self-assembly’.  There are 3 keys steps:

1. Enable Access Teams on the entity:

image

2. Configure a Template:

image

The template is what defines what permissions the Access Team members receive:

image

3. Add a “Users” sub-grid to the form via the configuration options shown below (you need to get this exactly right):

image

 

Using Multiple Templates

If you would like to use Access Teams but want to say grant some team members full access and others read-only access you can achieve this with multiple templates and multiple sub-grids. e.g:

I define a new template:

image

And then reference it on a second sub-grid:

image

And that gives me this:

image

 

Now, if you are trying this out and your sub-grid is not working right – perhaps its displaying unrelated users – try removing the sub-grid, publish the change and then re-add the sub-grid, making sure you set the Default View and and Team Template correctly:

image

I have found that if you set these wrong initially the sub-grid breaks and correcting the values doesn’t solve the problem, you need to recreate the sub-grid.

 

So, is this is a good feature?  Should you use it? 

If you aren’t dealing with large record volumes (e.g. hundreds of thousands or millions of records) then sure, consider it, but test the cascading behavior carefully to make sure team members get all the access to child records you expect.  Look out especially for non-parental relationships, they may give you grief. 

If you are dealing with large record volumes you need to use this approach with caution, just like you do when considering any large scale use of Teams and/or Sharing.  Microsoft have done their best to mitigate performance issues with this approach but its still vulnerable to POA explosion.  Your life is going to be a lot easier if you can get by with a Business Unit security model.  If it was my choice and I was not influenced by regulatory requirements a Business Units design would always be my approach.  Too often CRM customers have an unjustified need to lock down data access and it just causes unnecessary problems. So if you are a customer, re-think your requirements.  If you are a Consultant, push back, test the requirement.

Fixing the sub-grid user experience in CRM 2013

Microsoft made an odd design choice in CRM 2013 with their new sub-grid design.   By default, when you add a new 1:M sub-grid to a form to display a custom entity you will get the following user experience…

The user clicks the + icon to add a new child record via the sub-grid:

image 

 

CRM reveals a lookup control to allow the user to browse for an existing record:

image

Eek!  Why did you do that CRM?  I want to add a new record, why didn’t you pop the create form?

What’s happening here is CRM  is taking us down the “Add Existing Record” path rather than down the “Add New Record” path.   Think back to CRM 2011 and those 2 buttons you get when you give a sub-grid focus.  Clicking the Add Existing Record used to provide this type of user experience:

image

Now, I was never a fan of the “Add Existing” button in CRM 2011, it was never that useful.  So why Microsoft chose that behavior as the default for custom sub-grids in CRM 2013 is a mystery to me.

Let’s get back to CRM 2013 and carry on with the default user experience.  So the user clicks the + button and the lookup appears.  They don’t want to search for a record but the only thing they can do to move forward is click on the magnifying glass, this executes a search and reveals the lookup control’s search results:

image

Here we can pick a record from the search results or click “Look Up More Records” to pop the traditional CRM lookup window to broaden our search.  I‘m still just trying to add a new child record so these options aren’t of interest.  There is however a new + New button for me, so I’m going to press that.  That gets me to where I want to be, popping the create form so I can create my new child record:

image

Saving that new record automatically closes the form and refreshes the parent form revealing my new child record in the sub-grid:

image

So, we do get there.  But the user experience is not ideal.  Fortunately, there is a fix to this.  CRM chose to push us down the “Add Existing Record” path because this child entity has an “Add Existing Record” button defined in its ribbon XML.  You can see this if you call up the associated view:

image

If we edit the ribbon XML and remove that button CRM will change its behavior and pop the create form as soon as the user clicks the + in the sub-grid.   This is the behavior you will witness in most of the out-of-the-box sub-grids.   See, here’s an Opportunity sub-grid on the Contact form:

image

Clicking the + button pops the Opportunity create form (in this case it is the Quick Create form):

image

If you look at the Opportunity Associated View you will note there is no “Add Existing Record” button:

image 

Back to our custom sub-grid, I want to change the default behavior there.  I launch Ribbon Workbench and call up the Ribbon definition for my Truck entity.  I right-click on the “Add Existing” and select Hide Button:

image

Ribbon Workbench is showing me 2 buttons, I’m not sure why, I’m going to hide both.  Then I Publish the change:

image

And that’s it, an easy fix. 

Here’s the user experience now…

The user clicks the + button:

image

And up pops up the create form:

image

So, an unfortunate design choice from Microsoft but at least there’s a simple no-code fix.

Hope this helps someone.

🙂