C#, .Net, Sql Server, Salesforce, Dynamics CRM etc,
Charity and Not-for-Profit sector

Sunday, May 19, 2013

Charities and Hackathons

Someone asked an interesting question at a charity-focused hackathon I was at last year - along the lines of "This is the third year we've held this event to help Charities, why aren't more of them here with projects?". From what I've seen of (medium to large) charities, the answer would be along the lines of "the technology problems that charities have to deal with can't easily be tackled by a hackathon". Technology problems in charities tend to be things like:

  • Needing to modify existing systems to handle new initiatives
  • Correctly piping data from one system to the other
  • Bringing order to ad-hoc systems that have evolved in Excel
Those sorts of problems are hard to take to a hackathon setting because so much knowledge of existing systems, processes and data is needed to handle them properly. Whereas a good hackathon project is generally one that mashes data from X with APIs from Y and Z to make a new self contained app.

Hackathons are great for generating experimental new apps, but Charities are not well placed to take advantage of experimental initiatives. I've seen some great prototypes get built, but they rarely seem to be picked up by charities. I think its probably because decision makers in large charities can't generally divert time and funds from established programmes at short notice to plough them into experimental ventures.This is compounded by the 'post hackathon dispersion' effect - once the hackathon is over and the pizza boxes are cleared away, the teams tend to disperse and its hard to keep up momentum.

Hence, despite Hackathons (bunch of smart people with effort to donate) and Charities (worthy causes in need of help) being - on paper - a great thing to combine together, I havent seen it done in a really integrated way yet. Charity hackathons are great for sharing ideas and trying things out, but there's still some figuring out to do, about how can we can harness that effort for maximum lasting benefit.


Sunday, May 12, 2013

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.

Labels: ,