This is the second post in a three-part series of the common pitfalls nonprofits make when implementing Salesforce. At Cloud for Good, we often work with clients who have already implemented their Salesforce instances in the past. Typically, they come to us in search of a better way to manage their instance or to correct issues they are currently having with how their original implementation. In working through these projects, I have found three common pitfalls that lead organizations astray and have highlighted my top three in this series. This post focuses on the common pitfall of creating too many custom objects.
The great thing about being a nonprofit is your free access with 10 licenses to all the glorious features of Salesforce Enterprise Edition PLUS the managed Nonprofit Success Package (NPSP). You are given a lot of power right out of the gate to pretty much customize anything and everything you want within your instance. However, just because you have a Ferrari doesn’t mean you have to drive at top speeds everywhere you go. The key to success is moderation and this is especially true when it comes to custom object creation.
Even if an out of the box (OOB) function of Salesforce or NPSP doesn’t fit your business process exactly, you do not necessarily need to create an entirely new object. I once had a client who didn’t like the fact that the Opportunity object had a stage and probability field. As a result, they had created an entirely new Opportunity object to track their donations. They didn’t like two fields and threw out an entire object, losing key functionality as a result.
Instead of throwing the proverbial baby out with the bath water, consider workarounds such as validation rules, read only fields, page layout changes, or workflow rules to customize existing OOB components. This way you won’t lose out on critical benefits like integrations with 3rd party apps, reporting capabilities, or existing object relationships that really make NPSP a powerful package. Know that when you create a custom object you are starting from scratch – any relationships to other objects have to be defined through a Look-up Relationship or Master-Detail Relationships.
Things to remember:
- If the name of a standard object doesn’t fit your organizations own process names, consider changing the name of that object or field label. Almost all objects and fields can be renamed in Salesforce. Check out these links from Salesforce to learn more:
Considerations for Renaming Tabs and Field Labels in Salesforce
Rename Object Tab and Field Labels
- You can customize field and object names. You can also add custom fields, validation rules, workflow rules, and customize page layouts for most objects in Salesforce, even your standard and OOB objects.
- Consider using tools like Translation Workbench to change the related list labels and field labels of an item created through a managed package like NPSP. If users hate the word “Affiliations” this is a great way to essentially rename that object for the user while keeping its free functionality. Click here to learn more about using Translation Workbench for this purpose.
You may also be interested in these posts:
Six Simple Steps to Improve Your Salesforce User Experience
Common Pitfalls When Implementing Salesforce for Nonprofits: Custom Record Types
