One of the things I love deeply about the Salesforce platform is the host of free resources – including developer trainings – available to the community. If you haven’t checked out the new (free!) Trailhead curriculum it’s beyond awesome.
One of the problems with all that great content, especially for nonprofits, is that each training demo starts out with developing a custom “app” and a custom object. If you’re not familiar with custom objects and database frameworks, it would be like adding a new page to your excel spreadsheet. You’d have Contacts on one page, Organizations on another, and – your custom object – “Animals” on a third.
The power in Salesforce lies in its ability to quickly and easily customize the platform (particularly for non-developers), and so it seems, we should follow the tutorials and create custom objects in our own Salesforce database to track what is unique to our nonprofit.
Yet in the vast majority of cases, nonprofits should NOT create a custom object (even when they think they should!).
1) Inability to access core functionality in the system: Creating a custom object seems like a great way to distinguish what has no clear framework in Salesforce – animals, for example, or a class that the nonprofit holds for experts in the field. Yet what happens when you want to use standard Salesforce email templates to email class registrants, or (as some shelters do!) send a letter in the mail, addressed to the animal? Using a custom object for each of these cases would not make these things impossible – but would make them unnecessarily complex, and would prevent a nonprofit user from accessing standard Salesforce reporting functionality as it relates to other areas inside of Salesforce. A class could be modeled using the Campaign object, and an animal could be modeled using the contact object (see a great discussion of this in the Power of Us Hub – Salesforce login required), which would allow the user to use both email templates and grouping of people (or animals) into Campaigns. But what happens when you want to send an email to all the folks who attended that class via your integrated email tool? Or that acknowledgement letter using information about the animal? Not impossible, just unnecessarily complex.
2) No standardization against data already in the system: For a nonprofit, the value of data lies in its relationship to other data in the organization. Custom objects need to be architected to create the appropriate relationships to data already in your system. When a custom object is built it typically loses its immediate relationship to other similar data that might exist in Salesforce. This can happen especially with third-party applications that are trying to build an integration with Salesforce. Developers may build a custom object in place of Contacts, Organizations (Accounts), Campaigns, or Opportunities and stick all the integrated data in there, and then call it an integration (and as my colleague Tracy would say – “anyone can pee in the woods, it’s harder to build real plumbing”). The problem is that when you want to evaluate an advocacy campaign and its multiple components – petitions and donations – you can’t as easily compare the effectiveness if those two items (or their important relationship to each other) if they are not mapped in some way to a standard core object in Salesforce – for example “Primary Campaign”.
3) Difficulty to Access Data for Reuse: We worked with a family foundation that needed to track the fiscal sponsor of its grantees, and had done so via a custom object linked to the grantee’s organizational record. Yet the time came to optimize its operations – and they needed access to the fiscal sponsor data via the grant transaction record to easily merge grant acceptance letters and other official correspondence. This was really difficult with a custom object linked sideways to the grantee – I think of it like a first cousin once removed. Our solution was to map the fiscal sponsor to a parent organizational (Account) record (and create an audit trail on the transactional record in case they got a new fiscal sponsor, or became their own 501c3.).
4) Standard Reporting is Painful: Reporting is always the heart of do-or-die success in Salesforce. Creating custom objects always makes it more complex to do reporting, and particularly to report against other data in your system – particularly the other core Salesforce objects. We recently re-architected an organization’s core database structure because they were floundering with their setup of multiple layers of custom objects that couldn’t be consolidated and reported against each other – what were all the ways that they were interacting and impacting one school with their programs? It was nearly impossible to tell.
There are times when a custom object is appropriate and good – and in the hands of seasoned Salesforce consultants or admins who can architect the appropriate connections – they might even be the best solution.
But for the majority of nonprofits – ease of functionality, standardization against other key data in your system, and reporting, reporting, reporting – will set a stage in which you should think twice before using a custom object for any and all data that you believe is special. Consider first how special this data really is, and it’s similarities to core objects, before jumping to what can feel like an easy solution with potentially complex long-term consequences.