Breaking Down Internal Silos
I saw a presentation by a salesforce.com employee recently, and it included the usual slides that one sees at all salesforce.com presentations: Born cloud, reborn social; mainframe to PC to mobile; becoming a customer company, etc. The presenter talked about why using Salesforce is so beneficial for a company, and she said something that we have all heard before, and that is very true: Data silos are a bad thing. I paused and became lost in my thoughts, as this suddenly became one of the most important things I had ever heard.
The term “silo” has new meaning for me now that I work for FinancialForce.com. Skipping the general description and moving right to the technical part, we are a company that creates managed packages that are installed into customer orgs. These managed packages have huge benefits for us and for our customers, and they have some drawbacks. The biggest is that it has been impossible for customers to control data moving between different managed packages – or even to design the data flow with 100% certainty of how that flow would execute. If one were to write Apex triggers, one cannot know if the new trigger would fire before or after existing triggers included in each managed package. But more than the order of execution, it has been impossible to move data between different applications reliably while accommodating custom fields that might have been created on objects in those packages. (***) Let’s look at an example:
A company uses our Accounting (FFA) product for all its finances, and uses our Professional Services Automation product to manage its consulting team. Though PSA handles expenses, they want to use Concur to log all the trips and expenses, and then to track paid expenses in FFA. Essentially, we would call that a Services Resource Planning (SRP) customer with a Concur add-on.
How would we connect Concur and FFA? We have created data silos – and they both exist within Salesforce! My first response to this situation is to say that we should connect Concur and PSA – the customer should have expenses in Concur synchronized to expenses in PSA so that built-in reports and dashboards can be used and so that if one application is removed, no data is lost. Let’s complicate things and say that the customer has custom fields on the PSA Expense Report object and on the Project object so that even if FinancialForce.com and Concur wrote a trigger to synchronize all packaged fields between the two applications, that trigger could never account for custom field mappings. What now?
The customer could write triggers to do the integration. This would include accommodating every data change: insert, update, delete, and undelete… on every object involved in the mapping. This code would need to have test code written for it, and would not only be difficult to write and maintain, but if the customer were large enough, it could even take over a half-hour just to deploy the code inserts and updates from a sandbox to the production environment. And that is for each tweak. Thirty minutes is too long!
I have described what is, in effect, data siloing within the Salesforce Platform. Because companies – for good reason – choose to protect intellectual property, customers are facing situations in which they want to connect two managed applications… and the cost is simply too great.
This is why one of FinancialForce.com’s newest creations is so important. ClickLink is a declarative tool that runs “integrations” between two objects in Salesforce – any objects in any application. We have designed a tool internally to automate Sales Invoice creation from an Opportunity – one integration rule fires to make the header of the invoice, and then a second rule fires to create the line items. Rules can be set to copy from an object, and pull data from related records, to fire when a button is clicked, to email every time the rule executes, to log errors, and more. (My favorite is that an Apex scheduled job can run to use a List View of an object as a filter so that, say, each open Opportunity with Close Date < Today creates a Wall of Shame record for the Opportunity owner.) And, yes, a short block of trigger code – we provide a template to each customer – can fire it as well.
If I may speak technically here:
As applications written on the Force.com platform grow in complexity, and as companies release packages that build on their own packages, multiple “after” triggers on a given object, including one that a customer writes to move data to an object in another package, could fire out of order. ClickLink is the perfect integration tool for administrators. Because it is fully declarative, you don’t need to worry about writing code, testing code, deploying code, or any code at all. Just map your configurations and let it do its thing.
My only complaint about ClickLink is that I can’t find a better word to use than “integration.” But I don’t like integrations! Things are so much more simple when they all exist on the Force.com platform, but as we can see, silos are possible even within the platform. So whenever we see silos, what do we say? “HULK SMASH!”
This is just one of the tools that we are developing here at FinancialForce.com. There are others in the works, all created to make our customers more successful. Stay tuned for future posts, some about current products and some about our roadmap items. Great things are happening here!
(***) More code-experienced readers might design a trigger that uses Field Sets to allow for custom fields, but that is a workaround hack that is unsupported by salesforce.com, so we don’t use it.
Related Posts:Back Office Ecosystem Emerging on Force.com