Tag Archives: CRM 2013

CRM 2013 New Features: Quick View Forms

This is perhaps my favorite new feature in CRM 2013.  It is common for customers to want to see Contact details such as Phone Number and Email Address on ‘transactional’ forms such as the Case and Opportunity forms.  Previously we had three options to address this:

  1. Do nothing, train that users should click on the Contact to pop the Contact form to view those details
  2. Create custom fields on the Case / Opportunity form and duplicate / synchronize the data from the Contact record
  3. Embed an HTML web resource on the form that dynamically retrieves and displays this data  

Quick Views now provides a no code equivalent to #3 which looks like this:

image

I’ll demonstrate some creative uses of this new feature in a second but first here are the basics…

The Quick View form is configured using the CRM form editor just like you would a normal form:

image

You are however constrained when it comes to the form layout, you get one Tab that can contain only single-column Sections – i.e. you are configuring a single column form:

image

You can insert multiple Sections though and each Section can have a Label and can contain Fields, Spacers or Sub-Grids:

image 

Now onto some design scenarios you might not have considered yet…

You can chose to render Sub-Grids as Charts and add some visual interest to your forms.  In the below screenshot whilst the user is looking at an Opportunity they get a handy visual indicator of the Account’s open Opportunities and active Cases:

image

You can use a Quick View Form to add contextual help to a CRM form.  This is my bright idea of the year, I think this is very cool and I look forward to utilizing this on a project. Imagine you have multiple types of Opportunities and each Type has different considerations that we want to communicate to the user.  We could create an Opportunity Type entity and place a corresponding lookup field on the Opportunity form.   On that Opportunity Type entity we can populate some guidance into some custom fields and then use a Quick View Form to display those fields on the Opportunity form once the Opportunity Type is  selected.  That gets us a user experience like this:

image

The experience is immediate, the Quick View Form renders / changes on change of the lookup field. 

I have placed the Quick View Form on the right side of the form, you could also place it beneath the lookup field:

image

One concern I have is the Quick View Form seamlessly integrates into the CRM form so there is the potential for the user to be confused and think these are editable fields.  Placing the form on the right helps address this.

Anyone else have any creative ideas on how we can leverage this new feature?

Advertisements

CRM 2013 New Features: Business Process Flows

With CRM 2013 Microsoft have introduced the biggest user experience change yet, the process-centric UI:

image

For those of us that design solutions on Microsoft CRM this is where I think we need to spend the most thinking time as we study up on CRM 2013. 

In this post I’m going to walk you through the creation of a custom Business Process Flow and help explain how cross-entity flows work. 

 

Here’s my scenario, I need CRM to support the sales and delivery process for an IT Company that implements software.   The company’s primary business processes are in Sales and Delivery.   Traditionally they have tracked Opportunities and Projects in their CRM system and these have been quite disconnected experiences.   Their goal with CRM 2013 is to have a more integrated and consistent user experience where the system supports the process from opportunity qualification through to delivery of the project.   This integrated process looks a bit like this:

image

So, my plan then is to utilize CRM’s “Opportunity” entity and a custom “Project” entity.  I will surface a process centric UI across these 2 entities using the Business Process Flow feature in Microsoft CRM 2013.

Let’s jump straight to the interesting bit and have a look at the Business Process Flow configuration.   We access this from the Processes area in CRM (where we have historically configured Workflows and Dialogs).  The first thing I need to do is disable the existing Business Process Flows that exist for the Opportunity entity.   There are 2 that come OOTB, I need to do an “Add Existing” to pull these into my Solution and then deactivate them, otherwise they get in my way:

image

Now I can create my new Business Process Flow:

image

I define the Stages that relate to the Opportunity record and list the fields I want grouped under each Stage:

image

Next I add the Project entity and the Stages that relate to that entity.   I click the +/- icon and select the Project entity.   Here the UI offers the 1:M related entities for Opportunity that have been enabled for Business Process Flows (there is a new setting on the entity record for this): 

image

Now I define the Stages and select the fields I want for each Stage:

image

And this is how this all looks once I Activate the Rule and try it out on a new record:

image

Now what’s important to understand is at no point there did I configure the automatic generation of a Project record.  If you are looking for that functionality within the Business Process Flow editor I’m afraid I need to reveal it doesn’t exist, the Business Process Flow will not create a Project for you.   You have 2 options, either you utilize something like Workflow / JavaScript / Plug-ins to generate the Project once a certain event occurs, or, you leave it to the user to create the record as they transition Stages.   Let me show you what that second option looks like to the user…

Back on the Opportunity form the user will populate the fields for each Stage and then click the Next Stage button to move forward in the process:

image

The flag icon moves to the next Stage and the fields for that Stage become visible:

image

When the user gets to the Stage transition that spans the Opportunity and Project entities the user experience changes, the user is prompted to select a Project record.   CRM needs to know which Project record to continue on with.   If we haven’t programmatically created the Project record for the user there will be no child Project records to pick from and the user will need to create one on the fly.  Fortunately, this just takes a click:

image

And the UI is refreshed and the Project form displayed.  The process chevron remains providing consistency to the users.  Any new data captured from this point on writes to the Project record:

image

If you prefer to create the Project record for the user you can do this easily with a Real Time Workflow.   Below I have configured a workflow to trigger once the “Contract Signed?” field is set to “yes” (it needs a Save to fire though so keep that in consideration when using real time workflows, they’re still not as immediate as JavaScript:

image

With this enabled, clicking Next Stage to move from Close to Discovery will offer up the automatically created Project record to the user to select:

image

So the user experience doesn’t really dictate the need to automatically create the Project record, you just need to consider how you will default any values on the record if you don’t create it programmatically.   The relationship field mappings will help you out a little there.

Another area of consideration is whether you need to close out the Opportunity record.  Again the Business Process Flow definition won’t really help you but Workflow, JavaScript and Plug-ins will.

I find the out-of-the-box experience of the Lead to Opportunity process a little disjointed in this area.  In order to progress the process you need to use the Command bar and Qualify the Lead.  I don’t like that.   In my solutions I will endeavor to keep the user in the Process chevron so they all they need to do is complete fields and click Next Stage.

 

One last thing, in the Business Process Flow designer you can ‘close out’ the process cycle:

image

But all this does is allow you to define additional stages in your process where an earlier entity resume focus again (in my case this would be the Opportunity entity).  If you do this, you cannot go any further with the process – i.e. you cannot add any additional entities, it is intended for the last steps in the process.   Returning to and updating the Opportunity doesn’t make sense in my scenario but imagine you want a process flow that starts with Case, jumps into Appointment and then returns to Case.   That might make sense in a scenario where Cases are captured for on site service requests, a technician goes out and then the Case is closed out.

That’s it on this topic.  Hopefully this helps with your understanding of Business Process Flows.  If you have any insight add please share via the Comments below.  🙂

CRM 2013 New Features: Actions

Ok, so this feature took me a little while to get my head around.  I felt there was a fair gap between the conceptual description of the feature from Microsoft and the reality of how and when you would use it.   Hopefully this post speeds up the learning process for others.

Here’s when you would you use this new feature.  Imagine you want to execute some custom business logic in real time when a button is clicked or an OnLoad, OnChange or OnSave event occurs.  With CRM 2011 you would typically write some JavaScript and develop the business logic in code.  You might query values on the form, you might even hit the CRM APIs to query other data and then you might update values on the CRM form or hit the CRM APIs to create/update other CRM records or pop a URL.     The new Action feature allows us to relocate that business logic into a configurable rule (similar to a workflow rule) and provides a framework for executing that rule from JavaScript.  This means we code the invocation once and then we are done.  The business logic can then be messed around with through a simple GUI.

The common scenario for this I think will be for Approval processes.   Imagine we want an Approve button added to the CRM form and when that button is clicked we want stuff to happen. 

Here’s the steps (in completely the wrong order):

Firstly, add the button to the form.  In CRM 2013 we now have a Command Bar that replaces the Ribbon on most forms.  It is still customized the same way though.  Best bet at this point in time is to use the Ribbon Workbench utility, a CRM 2013 version was recently released.   The button will execute a JavaScript function.

Secondly, write your JavaScript function that will execute the Action.  This will need to be a SOAP call.  Sadly Microsoft have not provided a nice function for this yet.  Actions are defined with input and output arguments so when invoking the Action you can pass values in and then perform additional steps with the values it returns.  I’ve seen these steps documented in a nice lab internally, I assume this info will be publically availably in the SDK or on blog some where.  Let me know if you see a good walkthrough and I’ll reference it here.

Thirdly, configure your Action.   Here, you use the same GUI that you have used in the past for Workflows and Dialogs:

image

You define your Input and Output arguments:

image

And then you write your business logic using the normal Conditions and Actions you will be used to from your Workflow configuration days:

image

You can do some Check Conditions to perform different actions based on the input arguments:

image

You can create, update and assign records and send emails, etc.   And you can assign values to those Output arguments:

image

Your button will fire the JavaScript function which will invoke this Action.  The Action will process the inputs, perform whatever actions you have asked it do, then it will return the outputs to the java script function.  The java script will do whatever you want it to do with those outputs (update the form, construct and then pop a URL, alert the user).

Going back to the Approval scenario I could see the following working nicely:

  1. – The user changes an Approval field to Approved
  2. – A JavaScript function is invoked, it calls the Approval Action passing in the Opportunity Type and Opportunity Value
  3. – The Approval Action runs those Input arguments through a series of Conditions assigning values to an Approver field and a Approval Due Date field
  4. – The JavaScript function receives those Output arguments and uses them to populate corresponding fields on the form and to pop an alert to the user to inform them of the Approver that had been assigned
  5. – The user has immediate visibility of who has been assigned as Approver and is happy

I hope this helps others understand Actions a little better.  I do wonder what they have to offer over a real time workflow.  I think the choice between the 2 will take some careful consideration.  More learning required 🙂