Skip to main content

Salesforce and Dynamics CRM - Unwizzy Wizards

At the moment I am working for two different charity clients, both of whom are implementing CRM systems - one has gone for Dynamics CRM, and one has gone for Salesforce.

I like both systems. Both of them present a programmable platform that you can build on, with tons of features ready to go. Both offer steep discounts for Charities. They are direct competitors so there is already lots of discussion around the web about which is better. I don't think I want to get into that debate - they are both very respectable systems with different strengths and weaknesses. Perhaps I'll try and write about the differences sometime.

Whats suprising is how similar they are conceptually and architecturally. Presumably this has come about because they compete with each other for feature parity. They both have major entities called Contact, Account, Lead, Opportunity. They both have the concept of Tasks and Events. They both allow point-and-click field and entity customisation. They both have configurable trigger-based workflow rules. They both allow some customisation by simple point-and-click, and they both allow deeper customisation by writing code.

They both also have 'visual workflow' features that allow power-users to create 'wizards' - that is visual multi-stage UI components that lead the user through a certain process, gathering info and doing something with that info.
  • In Dynamics CRM they are called Dialog Processes
  • In Salesforce they are called Flows
Whats particularly interesting about the wizards is that both systems lumber them with a strange limitation that makes them - to my mind - very un-useful.

On paper, being able to make wizards for your CRM system via point-and-click is a very exciting feature. One obvious use-case is for data entry when the user is following a script - instead of giving the user a screenfull of fields to fill in, you can lead them through a nice simple wizard that asks them for key fields in a certain order.

In practice though, neither Dynamics CRM's "Dialog Processes" and Salesforce's "Flows" allow you to re-use optionsets/picklists that you have already defined. Lets look at some examples to illustrate the point:

In Salesforce, lets take the built in Contact object and add a new field called "Favourite Animal". Lets make it a picklist with, say, four values:



Here's the same thing being done in Dynamics CRM: Customising the built in Contact entity with a new field called "Favourite Animal" with a picklist of specific options:


Lets say that we want to make a simple one page "Wizard" that asks the user for a First Name, Last Name and Favourite Animal and then saves it to the database.

Here's a Salesforce Flow to do that:



Implementing the bit that asks the user for First Name and Last Name is easy. But with Favourite Animal we hit a problem: We can add a field of type "Dropdown List", but then we have to specify the whole set of choices (the list of animals) again. There is no way of re-using the list of animals we already defined when we added the field to the Contact object.

If your picklist has lots of values (e.g. "Country") then re-defining them all in the Wizard is going to take a long time. Worse, you now have the burden of keeping the Wizard version of the picklist in sync with the field version.

Here's the thread on the Salesforce Ideas forum where users are lobbying to get this fixed.

There is a workaround, but it is clumsy. Instead of defining your animal list as a picklist, you would define an Object called Animal and then create records for each picklist entry you wanted. This object could then be queried by the Flow using a "Dynamic Choice" element. But if you have lots of picklists, this means creating (and maintaining) lots of objects and their records. As an additional patch, someone has an Apex patch on GitHub called FlowPicklistSync that allows you to leave your picklists as picklists - the patch can then automatically convert the picklist to entries in a custom object, which can then be accessed via Dynamic Choice.

Lets look at the equivalent Dynamics CRM Dialog Process:


Again, First Name and Last Name are easy. But with Favourite Animal we hit the same problem: We can add a 'Prompt and Response' step of type "OptionSet" but then we have to define our whole optionset again. We can't re-use the one we already defined for the Contact field.

Here's a thread on the Dynamics forums discussing the problem.

As with Salesforce, there is a workaround, and it is conceptually very similar: You define a new Entity of type Animal. and add an entry for each row you want on your picklist. You can then query this dynamically into the Process Dialog, either using the 'Query CRM Data' option for the OptionSet Prompt and Response (and then putting the relevant FetchXML query into a Query Variable) or by using the 'Lookup' Prompt and Response field and pointing it at your entity. But if you've got lots of picklists, this is going to lead to lots of entities.

Again, there are lots of things I really like about both Salesforce and Dynamics CRM, but this limitation makes the point-and-click-build-a-Wizard feature very un-useful in both of them. Basically, if you build Wizards with non-trivial picklists in either system you are creating trouble for yourself down the line to keep the picklists in sync.

If you really want to make a decent Wizard in either Salesforce or Dynamics CRM, at the moment you're probably better off doing it via coding rather than point-and-click. That is, use Apex and VisualForce (for Salesforce) or Javascript or Silverlight (for Dynamics) to build the exact Wizard you want. It won't be point and click though.

It looks like the upcoming 'Orion' Dynamics CRM release (sometime in 2013) might offer an interesting alternative - the new Process Flow UI design is like a wizard UI pinned to the top of each screen. So the main screen is still there, but there's also a wizard-like component at the top to lead the user through key steps and fields. Its pretty interesting - more on that soon.

Comments

Popular posts from this blog

Copying data to Salesforce Sandboxes using TalenD

A common problem with Salesforce Developer Sandboxes is that they are blank. Really you're going to want some data in there, so there are various strategies for copying data from your live instance to the Sandbox. There are some paid-for solutions - SFXOrgData , Salesforce Partial Data Sandboxes - but if you've got a decent ETL tool you can build your own. There are a bunch of free ETL tools for Salesforce: JitterBit Data Loader is good for quick ad-hoc tasks but the free version makes it difficult to manage specific ETL projects or share projects with other users Pentaho Community Edition - an open source edition of the enterprise version Apatar was a free open source Salesforce ETL which still works but development seems to have stopped since 2011 TalenD Open Studio is an open source ETL tool For the task of copying data from live to a Sandbox, either Pentaho or TalenD Open Studio could be used, depending on preference. Here's a good comparison of the dif

SSRS multi-value parameters with less fail

SSRS supports multi-value parameters, which is nice, but there are a few issues with them. This is how I deal with them. Two of the problems with SSRS multi-value parameters are: You have to jump through a few hoops to get them to work with stored procedures The (Select All) option, as shown above The reason the (Select All) option is a problem is that it is a really inelegant way of saying 'this parameter does not matter to me'. If you have a list with hundreds of values, passing all of them as a default option just seems wrong. Also, if your report shows the user which items they selected, printing the whole list when they choose (Select All) is excessive. So in this post I'm going to show my particular way of: Jumping through the hoops to get Multi-Value params in a stored procedure Adding a single '--All--' value that the report interprets as meaning all the options. Getting Multi-Value params to work with Stored Procedures This is

Remote Desktop on High DPI screens

Scott Hanselman wrote a nice blog post back in January about some of the issues you might face running Windows on a High DPI screen like that of a Surface Pro or Lenova Yoga. I'm kindof mystified that he didn't mention Remote Desktop though because thats been the number one problem for me on High DPI screens. That said, if you remote into very recent Server OS's like Windows Server 2012 R2, then apparently Remote Desktop will sort out the DPI scaling automatically. Perhaps Scott hadn't noticed the Remote Desktop issue because he only remotes into Server 2012 R2. Certainly if I was Scott, I wouldn't remote into anything less than that. But, in practice, I regularly have to remote into Server 2008 machines and yes even Server 2003. If you do that from a high DPI screen, the remote desktop is rendered at regular pixel size, which makes everything tiny. Its hard to show screenshots of High DPI screens that correctly convey the pixel size, so I've photoshoppe