One of the great features of Salesforce.com is that it provides lots of different ways to customize the system, ranging from simple configuration all the way to building complex applications that look like anything you can envision. Many of our clients come to us with very specific requirements or visions about what they want their Salesforce.com system to do; sometimes it’s complex User Interface (UI) functionality, sometimes it’s integration with an external system, and sometimes it’s to mirror functionality that exists in their prior system. To people not familiar with the capabilities of Salesforce.com and the Force.com platform, it often seems that the easiest way to meet these needs is to write some code, whether it be a simple trigger to update some fields on a record or a set of complex VisualForce pages to automate a business process.
It is an interesting dichotomy that while writing custom code allows you to manipulate the system in very sophisticated ways, every bit of custom code that you write reduces the flexibility of your Salesforce platform by a very small degree, because it requires more specialized skills to keep running and to modify.
Many non-profits don’t have the resources or experience necessary to translate those visions into reality, so they turn to consultants or volunteers to help them. As consultants, our goal is to help you translate those visions into reality, but in many cases, the best thing we can do is to say ‘hold on, are you really sure you want to do that?’ and to really work through the implications of those choices before committing to building a lot of functionality using custom code.
Following are three key questions we would ask, and that you should ask yourself, before taking the step into the world of custom code.
1. Have you taken the opportunity to really think about why the code is required?
Often when migrating from an old system to a new one, people opt to try to migrate existing processes or functions along with their data without asking why they do the process. For example, in one popular fundraising system, there is a separate address table to track the history of a constituent’s addresses, and when migrating to Salesforce, people often ask us to write a trigger or similar function to preserve that same structure (they also ask us to migrate all of that history data, which is another story). What they most often don’t do, however, is to ask why need to keep the history of the last 10 addresses of a particular constituent or whether they have ever needed to use that information.
If you step back and evaluate the why question, you may well find that it’s not really necessary replicate the existing data and processes from the old system to the new, or that they new system provides new capabilities that the old one lacked. In the above example, simply turning on field history tracking might provide the necessary level of tracking.
2. Have you thoroughly evaluated what tools Salesforce provides to accomplish the job?
The toolbox available to a Salesforce administrator is large and grows with each new release (Salesforce provides three releases a year, each one chock full of new stuff). Many functions which would require custom coding in other systems can be accomplished through effective use of the declarative functions in the system – using clicks not code.
Let’s say you’ve got a business process where you want to be able to create a donor and log a donation and then send an email acknowledgement. In a standard process with no automation, you would first create the Contact, save the record and then create the donation record. After saving the donation record, you could then click on the new email button, select your template and send out the acknowledgement. This works well, as long as the person doing the entry is well-drilled in the process and remembers to complete each step. With automation, however, you can build a process that steps the user through a wizard-like format, making sure that all the required steps are followed, and even building in business logic such as using a different email template based on the size of the gift or notifying a senior team member if a particular donor makes a gift. Finally, if you’ve got interns or volunteers entering data, you might want to establish approval processes to make sure that a record doesn’t get committed until a full-time member of your Development team has approved the input.
In traditional systems, setting up complex workflow rules and forms to capture data input require custom development. In Salesforce, each of the options above can be managed by using features such as Workflow Rules, Approval Processes and Visual Flow (for an explanation of how Visual Flow differs from Workflow Rules, see our post here.), all without writing a line of traditional code. They are all accessible and can be managed through the Setup section of the native Salesforce interface.
Similarly, you should also be evaluating the tools provided by third party applications that are part of the Salesforce ecosystem for their ability to support your requirements. If you need to create and deploy online forms for volunteers to apply or for people to sign up for your advocacy alerts, you could create custom VisualForce forms or custom forms in a third-party Content Management System which send the data to Salesforce, but you could also leverage one of several online form-building platforms that already have integrations to Salesforce out of the box (Form Assembly and Form Stack are two) and integrate those into your website (read more here).
3. Have you evaluated how you are going to maintain and enhance your custom solutions over time?
One of the key factors that helped drive our move to the cloud when I was CIO at Citizen Schools was that I didn’t have to have the skillset on staff necessary to support a given platform (for example, when we shifted from Microsoft Exchange to Gmail, we didn’t need to worry about having someone make sure that the mail server was up and running, was patched properly to to administer upgrades). Similarly, when building applications on Salesforce.com, the more you can do from an administrative/declarative perspective, the easier it is to maintain. I know this from experience.
The minute you build a VisualForce form, write an Apex trigger or develop a scheduled Apex process, you are taking on a maintenance burden that will last until you retire that set of code (which can take a loooooong time). The more code you write, the bigger the maintenance burden, and the more complex the learning curve for the new staff person who comes on to replace the person who wrote the original.
When you’re working with consultants to write code for you, the problem becomes even worse. At least if your own staff member does something, they can fix it if it breaks or make changes when your needs change (and they’re going to change, accept that). Your consultants are, by definition, going to be moving on to the next project, and when you need them, there’s no guarantee that the person who wrote the code that needs to be changed is going to be available (or even working for the same company). If they’ve done their job well, they’ve documented what they did and how it works, which provides a trail that someone else can follow. When you’re in a mission-critical situation, however, waiting while someone else is trying to get up to speed is not what you want to be doing.
I’m not trying to imply in this post that you should never go the custom route, as there is a time and place for it, but you should seriously weigh the costs against the benefits and try to put some measures in place to mitigate the risks – here are a few:
-
If someone external is doing the work, make sure that they’re documenting what they’re doing very well and that someone on staff has a good understanding as well (at least from a business perspective, if not a technical one)
-
Consulting firms may also support contracts; depending on the degree of customization, engaging some ongoing support may be a way of hedging against the risk of something breaking or giving you some flexibility to make changes in the future
-
Keep evaluating the changes in Salesforce and identify when there is the opportunity to retire some set of custom functionality in favor of newly enhanced or released standard functionality.
I have to confess that I’ve been in situations where I didn’t ask these questions and it required substantial scrambling to compensate when we ran into trouble. Save yourself some headaches by planning ahead!
