When you create a custom object or field, Salesforce suggests an API name by swapping spaces for underscores. Most teams accept it and move on. A few years and a few hundred fields later, nobody can tell what a field holds without opening Setup.
A naming standard fixes that. The goal is simple: anyone reading an API name should be able to tell what it is and what kind of data it holds, whether they're an admin, a developer, a report builder, or an integration partner. This is the standard we use on every build. It pairs with our Flow naming conventions.
Objects: clean names, no underscores
- Remove the underscores and use PascalCase. The label
Opportunity CompetitorbecomesOpportunityCompetitor__c, notOpportunity_Competitor__c. Salesforce's suggestion has to be fixed by hand. - Get the plural label right. Salesforce's default plural is usually fine, but not always. Check it.
- Never reuse a label. Two objects with the same label make Object Manager, reports, and lookups confusing.
- Choose the record name on purpose. If records have a natural name, keep a Text
Name. If they don't (settings, junction objects, system records), use an auto-number and relabel the field from "Name" to Code, with a meaningful prefix likeOC-{00000}. "Code: OC-00042" reads far better than "Opportunity Competitor Name: OC-00042". - Always fill in the Description. One sentence on what the object is for saves the next admin from reverse-engineering it.
Fields: let the name tell you the type
Is EffectiveDate__c a Date, a Date/Time, or a formula? Without a convention, you have to open Setup to find out. We encode the data type into the API name so it's obvious at a glance, especially when you're writing formulas, validation rules, flows, or Apex.
Checkboxes read like a question
Start with a lowercase verb: isActive__c, hasOpportunities__c, canBeCloned__c, shouldNotify__c. The label stays short ("Active"), while the API name reads as the yes-or-no question it answers.
Dates and times say so up front
Dates start with Date_ and date/times with DateTime_, followed by the event: Date_Signed__c, Date_LastContacted__c, DateTime_Sent__c. You'll never again pass a Date/Time where a Date was expected.
Calculated fields get a suffix
Formulas end in _f and roll-up summaries in _ru: TotalAmount_f__c, TotalAmount_ru__c. You immediately know the value is calculated and can't be written to. A checkbox formula combines both rules: isPastDue_f__c.
Lookups end in Id and name their target
A lookup or master-detail field holds a record Id, so the API name ends in Id, just like Salesforce's own AccountId and OwnerId. If the field's role doesn't already say which object it points to, add the object name: a lookup to the User who is the account's BDR is BdrUserId__c, not Bdr__c. Read the name aloud and ask, "What does this Id point to?" If the answer isn't in the name, add it.
Percents say Percent
DiscountPercent__c reads clearly in a formula. Discount__c or Discount_pct__c leaves people guessing whether it's a percent, an amount, or a flag.
Don't skip the child relationship name
Every lookup and master-detail field also has a Child Relationship Name. It's the name you use to get from the parent to its children in SOQL, reports, and Flow. Salesforce's default works until an object has two lookups to the same parent, and then it gets confusing fast.
Our pattern is <ChildObject>As<Role>. The BDR lookup above becomes AccountAsBdr on User, which reads as "accounts where this user is the BDR". For junction objects we use the plural: OpportunityCompetitorsAsCompetitors.
Quick reference
| Field type | Pattern | Label | API name |
|---|---|---|---|
| Checkbox | <verb><Name> | Active | isActive__c |
| Date | Date_<Event> | Signed Date | Date_Signed__c |
| Date/Time | DateTime_<Event> | Sent Date/Time | DateTime_Sent__c |
| Formula | <Name>_f | Total Amount | TotalAmount_f__c |
| Formula (Checkbox) | <verb><Name>_f | Past Due | isPastDue_f__c |
| Roll-Up Summary | <Name>_ru | Total Amount | TotalAmount_ru__c |
| Lookup / Master-Detail | <Role>[<Object>]Id | BDR (User) | BdrUserId__c |
| Percent | <Name>Percent | Discount % | DiscountPercent__c |
| URL | <Name>Url | Website | WebsiteUrl__c |
| Text, Number, Currency, Picklist | <Name> | Annual Revenue | AnnualRevenue__c |
A few habits that make it stick
- Never give two fields on the same object the same label. Reports and list views become guesswork.
- Write help text for any field users see where the label alone isn't enough.
- Write a description for every formula and roll-up, explaining what it calculates and why.
- Agree on the standard before the build, not after. Renaming API names later means touching every formula, flow, and integration that uses them.
Consistent names are a big part of what makes a Salesforce org easy for the next person to understand and change. That's the whole point of how we build: an org your own team can run.