Stick to the Core: When Nonprofits Should Think Twice About Building a Custom Object in Salesforce

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!).

Here’s why:

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.

Megan Himan has over fifteen years experience in the nonprofit sector and over ten years working on the Salesforce platform. She has a unique combination of deep technical skills paired with an ability to strategically convene groups, coach executives and leadership through transitions, and execute on project deliverables. She is Founder & Principal of BrightStep Partners - solutions with strategy for Salesforce success. In September 2017, she was named a Salesforce MVP.

Tagged with: , ,
Posted in Administration, Best Practice, Implementation Success, Planning
3 comments on “Stick to the Core: When Nonprofits Should Think Twice About Building a Custom Object in Salesforce
  1. New Admin says:

    Seems the same can be said for various “apps” – especially those Salesforce Labs ones which look great upon release and then slowly decay over time without support and after several Salesforce updates (or whatever external cloud app with which they try to integrate) years later…

    Liked by 1 person

  2. […] build one” or you may be tempted to build something to track a business process. Wait. Read this Blog Post. More than likely, someone has solved this issue before. There are reasons to build custom objects, […]


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Our (New!) Blog Site
Visit our new Blog location!

Visit our new Blog location!

Our Consulting Site
Follow BrightStep Partners on
%d bloggers like this: