There’s a temptation that just because you can rename standard objects, you should. Common examples are
- Contact –> Person
- Account –> Company
- Opportunity –> Project
Here are several reasons why this is a bad idea.
1. Inconsistency
It’s generally bad design practice to have the label and API name be different. This applies to both fields and objects. The renaming itself isn’t consistent. Some people will see the renamed objects, while others won’t. For example, when building a custom report type, the object names will always show the standard names, not your renamed version.
And just think how annoying it already is for the standard objects Salesforce renamed. For example, OpportunityLineItem vs Opportunity Product.
2. Resisting Salesforce
More often than not, the desire to rename something is because people are more familiar with other labels, or labels used in another system. That’s not a very good reason to rename objects. Ask yourself, what’s the real business value in renaming Contact to Person? When adopting Salesforce, it’s normal to resist change, using Salesforce terminology and practices are part of the adoption process.
3. Support
If users need to search for help online, they may be able to find answers in Trailhead or in any number of Salesforce-related websites. It’s easy to find helpful documentation and best practices for things like opportunities, since that’s the name of the object. If it’s renamed to “Projects”, these resources won’t be as helpful, or perhaps they won’t even find what they are looking for.
The takeaway
When asked to rename a standard object, be sure to ask why. And perhaps follow-up with a few more “whys”. Be sure the reason is legitimate and consider the impacts before proceeding.