2

I'm a SF architect for my company and set standards and conventions for my admin and development team. Our company is a large enterprise that is made up of a number of acquistions, close to 20 in total. I routinely am asked to change the names of standard objects, e.g - Accounts -> Businesses, Contacts -> People, Opportunities -> Deals. I think most of this comes from the marketing terminology that is being used in the digital marketing/demand gen products (Hubspot). My knee jerk reaction is to deny these requests and I give the following reasons:

  1. Discrepancies between API name and Label is misleading and usually causes confusion for integration engineers and new admin teams. Plus I despise it.
  2. Dependencies - I don't know how a managed package uses standard objects, therefore I can't possibly know what might happen in the label changes.
  3. I am of the opinion that if an object doesn't match the definition expected by the business, a custom object should be created to match their definition (if justified). Otherwise, use the standard object and create a training exercise to use it appropriately.
  4. Future acquisitions will need to adopt this new definition. It may not always "fit"

I ALWAYS get pushback on this and I always fight with the same argument. My question - what other criteria is there to help defend my position? Are there other reasons for not renaming standard objects?

1
  • I'm 100% behind you on this one; especially if many acquisitions meaning some standard is needed so it might as well be the SFDC standard object name
    – cropredy
    Commented Jan 12, 2022 at 18:44

1 Answer 1

2

While I'm not an architect, and haven't seen nearly as many acquisitions (and have been on the acquiree side more often than not), one thing that I/my boss have used in evaluating more routine requests is this:
Who will this change affect?

Many changes that we can make (such as re-labeling objects and fields) can end up affecting everyone. A change might be valid and valuable for one department, but does it run counter to or harm another department?

Implementing changes that affect everyone means that people need to be trained on that change (and even then, there will still be a period of months where people will make mistakes and need technical support).
What value does making such a change bring, and does it offset the cost to those that need to adjust?

To wrap that up nicely: What is the business case for making such a change, and what value does it bring?

I'd also not underestimate your first point. Any disconnect between the label and the API name is going to cause pain (especially for developers and admins). It's annoying enough when Salesforce does it themselves (looking at you, Assets/Services and OpportunityLineItem/Opportunity Product)

This argument is probably most effective when you use Salesforce for more than just the Lead/Sales pipeline, and less effective if are separate orgs for each team/business unit.

1
  • That's a great point. I will add to the equation also "is there a workaround?", which was a favorite in a product management round I was part of. In your case, the answer likely is yes, namely: train people to understand the standard names. And if the answer is indeed yes, the business case / value can get pretty slim. Commented Jan 12, 2022 at 15:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .