Error (bug?) when creating records from Dynamics CRM updated-mode forms

I'm working on a project with CRM Online, and I just found a significant difference between how records are saved from updated-mode forms as compared to classic-mode forms.

I had added the territory field to the OOTB "account" form, and I also created a new security role based on the OOTB "salesperson" role, but I neglected to add append-to rights to the territory entity. Because of that configuration (actually mis-configuration in this case), I would have expected CRM to throw an error if a user in my custom salesperson role attempted to create an account linked to a territory, but it should have worked fine if the user left territory blank. As it turns out, that only partially worked as expected.

The user could create a new account record with a blank territory from a classic-mode form, but when creating a new record from an updated-mode form, the create process would just sort of hang. Eventually if the user closed the form, a CRM system error message was displayed, and the record never got written to the database. Once I added append-to rights on the territory to my custom "salesperson" role, creating a new record with a blank territory worked fine from both types of forms.

I wonder if there is a reason for this discrepancy or if it's just a bug? If you've had any personal experiences or have any insight, please share in the comments.

Continue Reading »

An article by Lucas Alexander No Comments

Scheduling recurring Dynamics CRM workflows with FetchXML

In today's post I will show how to set up a recurring process in Dynamics CRM that executes a FetchXML query to return a set of records and then starts a workflow for each of those records without requiring any external processes or tools. This is a generalized approach to solving a class of problems that includes the following scenarios:

1. The birthday greetings problem: How can you, on a daily basis, send an e-mail to every contact with a birthday == today (where the date value for today is obviously different every day)?
2. The monthly update problem: How can you, on a monthly basis, generate an activity for every account with status reason == X (where it's important that the process only runs on a certain day of the month based on status reason values as of that exact date)?

While you could accomplish both of these using workflows with timeouts, I think that would be a bad approach. In the case of the birthday greetings problem, I don't like to have workflows in a waiting state for an entire year. For the monthly update problem, a timeout-based approach could get extremely complex. Another more general issue with waiting workflows is that business rules can change, so if you have thousands of workflows in a waiting state and the business owner says she wants to update the process to do X instead of Y, it can be a serious pain to cancel the waiting workflows, update the definition and then restart them. (And yes, I speak from personal, painful experience.)

My solution requires three things:

1. A custom workflow activity (StartScheduledWorkflows) that can execute a supplied FetchXML query and initiate the workflow for each retrieved record.
2. A custom entity (Scheduled Process) to hold the FetchXML query and scheduling details.
3. A workflow (Scheduled Workflow Runner) to run the StartScheduledWorkflows activity on a recurring schedule.

How it works

A Scheduled Process record is created, which starts a corresponding Scheduled Workflow Runner workflow in a timeout state. When the next run date == the current time, the Scheduled Workflow Runner workflow initiates the StartScheduledWorkflows activity with the FetchXML query and workflow lookup from the Scheduled Process record. The StartScheduledWorkflows activity advances the next run date of the Scheduled Process record, and then it executes the FetchXML, loops through the results and starts the workflow from the lookup for each record. A newly started Scheduled Workflow Runner workflow then waits for the next run date to start the process again. More...

Continue Reading »

An article by Lucas Alexander 5 Comments

Creating a dynamic dialog launcher menu for Dynamics CRM

I love Dynamics CRM dialogs. In fact, I think they are one of the best features of CRM 2011. What I don't like about dialogs is how the user has to run them when working with a entity record. On a "classic" mode form, the user has to go to the ribbon, click start dialog and then find the dialog in a list. If there are lots of dialogs for that entity type, the user then has to spend a lot of time looking, change the view or search. That experience is still better than on an "updated" mode forms where the user can't run dialogs at all without switching to classic mode. It is possible to launch a dialog via a URL from a web resource embedded in a CRM form using the format described here, but that approach requires you hardcode the GUID for the dialog you want to open. In this post I will show how to create a web resource dialog "launcher" that you can embed in a CRM form (both classic and updated modes) with JavaScript and an OData query.

Originally when I started looking at this, I was thinking about just a single dialog launch button, but then I remembered the "macros" system I created originally for CRM 3, and I realized that a dynamic dialog menu would achieve a lot of the same goals without anywhere near as much custom code. That being said, the approach I am going to show will allow you to create a menu that displays either a single dialog or multiple dialogs depending on exactly how you want to make them available to your end users. More...

Continue Reading »

An article by Lucas Alexander No Comments

Updated "Unit testing Dynamics CRM C# interfaces code using NUnit and Moq" code sample

Back in January, after I published my How to unit test C# Dynamics CRM interface code - part III post on how to use NUnit and Moq to test Dynamics CRM interfacing code, I uploaded my project files to the MSDN code gallery. Earlier this week I revisited my original solution while preparing a demo for some of my colleagues. I updated the original solution version from Visual Studio 2010 to Visual Studio 2012, and I put the unit tests in their own project. I also added another project with the same unit tests written against the Visual Studio Unit Testing Framework to show how the same concepts work with it.

Here's the link to the updated code sample in the gallery: http://code.msdn.microsoft.com/Unit-testing-Dynamics-CRM-967a04ec.

You can also download the original Visual Studio 2010 solution here: LucasDemoCrm.zip (620.73 kb)

Continue Reading »

An article by Lucas Alexander No Comments

Documenting a Dynamics CRM custom workflow activity with Doxygen

In this post I will show how to document a Dynamics CRM 2011 custom workflow activity assembly and use Doxygen to generate a compiled HTML (CHM) help file. (Doxygen can actually generate documentation in a variety of different formats, but I'm partial to CHM files because they're entirely self-contained.) For this example, I have a project that consists of these three C# files:

1. CalculateDateByBusinessDays.cs (2.05 kb)
2. DoSomething.cs (6.78 kb)
3. JsonRequestResponse.cs (1.89 kb)

And the final output will be this generated CHM file: LucasWorkflowDemo.chm (76.94 kb).

Although this sample is focused on documenting an assembly that is used as part of a Dynamics CRM solution, the overall documentation approach and techniques are applicable to any C# project.

Before we look at how to document code using Doxygen, let's step back and take look at the broader problem we need to solve. Put simply, getting software documented properly after it's written is a pain. More...

Continue Reading »

An article by Lucas Alexander No Comments