Hey guys,

I wrote this document hoping I can get someone to listen at DreamForce this year.  I wanted to place it someplace people will be able to easily find so I'm putting it here.  Document pasted below.

Rick

Force.com Flaws by Richard Bergen at Nook Industries in Cleveland Ohio on Decemeber 2010

I was asked to gather my thoughts so that at our third DreamForce perhaps we can get the right people the right information so they can make Force.com a more viable and robust platform option.  We’re moving everything to Force.com due to all the benefits, and we have all our employees as users.  So to speak I’ve drunk the Kool-Aid, and now I’m just hoping it wasn’t poison.   As I thought others might benefit from this information gained from pounding my head against a brick wall for three years, I’m sharing it.  Here’s the shortened list:

Workflows are fundamentally flawed in so much that any “Field Update” puts data and process consistency at risk due to the “workflows don’t trigger other workflows” hack that was employed to avoid infinite loops.  Workflows should always fire when their conditions are met!   This is particularly problematic in time based workflows because actual actions are being taken inappropriately.  Also, this completely blocks multi-stage business processes being implemented via workflows.

Picklists should be able to be dynamic from both an external source or a custom object.  There shouldn’t be a limit to the number of picklist values.  Lookup relationships should be able to be conditional and dependent, e.g. select a contact on an opportunity but only those contacts for the account specified by the opportunity.  In fact, it should be possible for the lookup relationship UI to appear similar to a picklist so the user won’t need to search to select something if there aren’t many options to select from.

Salesforce.com bypasses triggers sometimes in certain known (a help page lists them) and unknown circumstances such as some of their specialized standard object pages, e.g. contact email update page.  The whole idea of a trigger is that it is always triggered.  If I want a trigger to do nothing in certain circumstances, I would code it (or them all) to do so.

Force.com seems to lack concurrency control between separate transactions performed by the same user, e.g. API, Scheduled Apex, Batch Apex, or even multiple UI.  This is easily demonstrated by opening up the same record twice in standard UI.

"A batch Apex job that contains 1,000 records is considered five transactions of 200 records each."  What about when it is only acceptable if it is committed / rolled back as a single transaction?

Apex triggers cannot do synchronous web callouts.  That means we can’t do perfect real time synchronization or validation.

Although Force.com performs well when interacting with data that is two or three related objects deep, it performs very poorly in all areas with chains of three or more relations or in N-to-N relationships.  This is evident in extreme (and sometimes in not so extreme) cases via reaching governor limits, lack of ability to display on the object detail view page of a related list “once removed” (e.g. to display N-to-N appropriately), lack of conditional aggregate data sometimes being easily gathered, lack of ability to query deep enough or appropriately in SOQL, etc.  Note that master/child relationship efforts do not address this in any way because they are often unusable due to the forced cascade deletion of child objects.

There are some odd actions that are performed with regard to child record summary rollup fields.  They are actually updating the parent record when the child record is updated.  Conceptually, they “should” act like a “formula that references another record”.   An update to the child is not an update to the parent.  The parent just has a different value for its formula, i.e. summary rollup.  The fact that this update actually kicks users off the parent record if they are editing it makes summary rollup fields often unusable.

There are many more issues, concerns, and roadblocks that prevent Force.com from being a viable solution for us in many cases.  Although the concept behind Force.com is a step forward with regard to Platform as a Service, it still has a lot of needed work to be done.  Otherwise, wouldn’t Salesforce Standard Objects have been coded using it by now?