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.