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.

About these ads

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.

:)

Phone Apps released for Microsoft CRM 2013

Microsoft have released their first ever mobile phone apps for Dynamics CRM.  Here’s the iPhone app:

image

There are distinct apps available for Windows Phone, iPhone and Android.  These are native apps that need to be installed from each vendor’s respective app store.

You can view, edit and create new records.  There is support for views and forms and viewing and editing of related records. 

Looks to be no offline support, not even the recently viewed records like on the tablet (just read you get this in the Windows Phone app only).

You can click to call on a phone number, click to email on an email address and click on a URL to pop the browser.  In all 3 cases you leave the app though so have to navigate back to it once done.

One cool feature is you can attach photos from your mobile device’s camera roll to a CRM record via a click of a button:

 

A massive improvement over Mobile Express but it still leaves room for products like Resco and CWR Mobility (e.g. offline support, extensibility, hundreds of little features).

More details available here:

https://community.dynamics.com/crm/b/crmteamblog/archive/2013/11/20/microsoft-dynamics-crm-for-phones.aspx

From a configuration perspective your configure this app the same way you configured Mobile Express in the past.  There are Mobile Forms in the CRM solution editor:

image

And the default public view is what renders on the mobile device (the first 2 columns at least).

To enable/disable entities for mobile support there is a property on the Entity record (which you can both check and uncheck):

image

When making configuration changes make sure you kill the mobile app on your device in order to pick up the new changes.

I did a quick test and Business Rules don’t appear to fire, which suggests JavaScript won’t fire either. Makes sense, as you can’t associate either of these to Mobile forms.

One minor annoyance with the Mobile apps at the moment is you can’t reconfigure them to point at a different Org.  To do that, you need to delete the App and reinstall it.  Well, that’s one way to notch up a lot of downloads I guess!  ;)

CRM 2013 New Features: New Menu Experience

Gone is the traditional left hand navigation pane, now we have a top menu that admittedly takes a little getting used to:

Out with the old:

image

And in with the new:

image

At first glance the menu doesn’t feel that intuitive.  For example to switch Areas you click on the Microsoft Dynamics CRM dropdown:

image

This seems strange to me.  But then again, in my experience most customers use CRM for only one functional area and I have commonly ditched Sales, Service and Marketing and replaced with a single custom area named something like “CRM” or “Home” – whatever looks good in the UI.  So I expect it will be common for users to not need to switch Areas making this peculiar user experience irrelevant.

Next level of navigation is to pick a menu item from within the selected Area (i.e. pick Opportunities from the Sales Area).  Here you click on the SALES dropdown, to pick the child menu items that belong under that Area:

image

It will be common for the number of menu items to exceed the width of the window, so the user will need to use the arrow on the right to scroll across:

image 

The Groups that we are used to from the SiteMap are still there, they appear as subtle headings above the first menu item in each Group.  Not sure I see any value in these now:

image

Editing of the new menu is done the same way as it was before, either manual XML editing of the SiteMap or via a third party SiteMap editor.   

Let’s try trimming the menu down and see if we can’t make the menu a little more intuitive.  I gave Microsoft’s Site Map Editor a whirl and it seemed to work just fine against CRM 2013.  I created a “MAIN MENU” Area and placed my menu items there and then deleted the Sales, Service and Marketing:

image

This approach results in what feels like a more intuitive user experience to me:

image

With the user accessing menu items from the MAIN MENU dropdown:

image

Its going to be interesting to see what sort of Site Map configurations work best in CRM 2013.