Record Name
A Record Name is the standard identifying field that every Salesforce object carries, holding the human-readable label that appears in list views, lookups, search results, and related lists.
Definition
A Record Name is the standard identifying field that every Salesforce object carries, holding the human-readable label that appears in list views, lookups, search results, and related lists. On the Account object it is the Account Name, on Case it is the Case Number, and on a custom object it is whatever Name field you defined when the object was created.
The Record Name can be one of two data types. A Text Name asks the user to type a value when they create the record, like a company or project title. An Auto Number Name generates a sequential value automatically using a display format you set, like INV-{0000}, so each record gets a unique number without anyone typing it.
How the Record Name field shapes your data model
Every object has exactly one Name field
When you create any object in Salesforce, the platform gives it a small set of standard fields automatically, and the Name field is one of them. You cannot delete it, and you cannot add a second one. It is the field Salesforce treats as the record's title everywhere a record is referenced. Open a list view and the Name column is usually the clickable link. Add a lookup to the object and the picker shows Name values. Run a global search and the Name is what gets matched and displayed in results. Because of this central role, the Name is the first thing most users read when they scan a screen full of records. On standard objects the Name field already exists with a fixed behavior, so Account uses a free text Account Name and Case uses an auto-generated Case Number. On custom objects you get to decide. That single choice, made at object creation, quietly drives how every report, every related list, and every lookup reads for the life of the object. It is worth a few minutes of thought rather than a default click.
Text Name versus Auto Number
The two data types solve different problems. Pick Text when the record has a natural, meaningful title that a person can supply, such as an account, a campaign, or a property listing. Users type the value, and you can require it so records cannot be saved blank. A Text Name on a custom object holds up to 80 characters, while the standard Account Name allows up to 255. Pick Auto Number when there is no obvious human name, or when a clean sequential identifier carries real value, such as invoices, support tickets, or asset tags. The platform fills the value for you using a display format, so users never see an empty field and never have to invent a number. A practical example: an Order object usually works best as Auto Number (ORD-{0000}), because nobody wants to name orders by hand, and a tidy running sequence is easy to reference on a call. A Contract Template object, by contrast, reads better as Text, because a human title like Standard NDA 2026 is far more useful in a lookup than a number.
Reading the display format
An Auto Number Name uses a display format that mixes literal characters with a numbered placeholder. In INV-{0000}, the INV- is printed on every record and the {0000} is the running counter, padded to four digits, so the first record becomes INV-0001. You set a Starting Number too, which controls where the counter begins. Salesforce also supports date placeholders inside the format, so you can build values like {YYYY}{MM}-{0000} to fold the year and month into the identifier. One behavior surprises people: the digit count is a minimum, not a hard ceiling. Salesforce documents that once the sequence reaches the capacity of the specified digits, the number portion expands an extra digit to keep going. So A-{0000} runs A-0001 through A-9999 and then continues at A-10000 rather than stalling or resetting. That means you never lose records to overflow, but it also means your padding only stays uniform up to the point you planned for. If consistent width matters for an external system, give yourself more digits than you think you will need.
Changing the Name type after records exist
You are not locked in forever, but conversions take care. You can switch a Name field from Auto Number to Text and back, and Salesforce uses this round trip as the supported way to reformat existing values. The documented pattern is to change the field type to Text so the values become editable, export the records with Data Loader, fix the values in a spreadsheet, mass update them back in, then switch the field type back to Auto Number. The single most important step is the Starting Number. When you flip back to Auto Number, set the Starting Number higher than the highest number already present on your records. Skip that and the counter happily reissues numbers that already exist, which produces duplicate identifiers and confused users. Going the other direction, switching Text to Auto Number, replaces whatever titles users typed with generated numbers, so only do that when you genuinely want to abandon the old labels. Treat any Name conversion on a populated object as a small data migration, test it in a sandbox first, and communicate the change before it lands.
How the Name shows up in SOQL and relationships
The Name field is the value you almost always pull when you traverse a relationship in a query. Instead of showing a raw eighteen character record Id on a child record, you walk the lookup and read the parent's Name, which is why SELECT Name, Account.Name FROM Contact is such a common shape. The same idea applies to ownership and other parent links, so Owner.Name returns the readable owner rather than an Id. Reports lean on this too. A report on a child object can display the parent Name column because the platform resolves the lookup to that identifying field. This is exactly why the Name matters beyond cosmetics. A weak Name, like an auto number on an object where people actually need to recognize records, makes every report and every related list harder to read, because the only thing on screen is a code nobody has memorized. A strong, meaningful Name pays off in every place a record is referenced, not just on its own detail page. Choosing it well is one of the highest-impact small decisions in object design.
Common mistakes and how to avoid them
Two patterns cause most of the Name field regret. The first is using Auto Number on an object where users genuinely need to identify records by sight. A custom Project object numbered PRJ-{0000} looks neat until a manager opens a related list of fifteen projects and cannot tell which is which without clicking into each one. If a human title exists, prefer Text. The second pattern is naming everything Text and then drowning in duplicates and typos, because free text invites inconsistency. There is no built in uniqueness on a Text Name, so two records can share the same title, which breaks lookups and confuses search. Where uniqueness or clean sequencing matters, Auto Number removes the human error entirely. A middle path many teams use is an Auto Number Name for the system identifier plus a separate required Text field, often surfaced through a compact layout, that holds the friendly label users actually read. Whatever you choose, decide deliberately at object creation, because changing course later means a data migration rather than a checkbox.
Set the Record Name when creating an object
When you create a custom object, Salesforce makes you define its Record Name field on the same screen. These are the settings that matter and how to think about each one.
- Open the New Custom Object screen
In Setup, go to Object Manager and click Create, then Custom Object. Salesforce presents the object label, plural label, and a Record Name section in the same form, so the Name decision happens up front.
- Choose the Data Type for the Name
Set Record Name Data Type to Text when users will supply a meaningful title, or Auto Number when the platform should generate a sequence. This choice drives how the object reads everywhere, so match it to how people will identify records.
- Configure the format if Auto Number
Enter a Display Format such as CAS-{0000} and a Starting Number such as 1. The literal text prints on every record and the placeholder is the padded counter. Add date tokens like {YYYY} if you want the year baked into each identifier.
- Save and verify on a test record
Finish the object, then create one record and confirm the Name behaves as expected. For Auto Number, check the first generated value. For Text, confirm the field is required if you intended it to be, so records cannot be saved without a title.
Text for user-entered titles, or Auto Number for a system-generated sequence. This is the core decision and is set when the object is created.
The pattern for generated values, mixing literal characters with a numbered placeholder like INV-{0000}, plus optional date tokens such as {YYYY}{MM}.
The value the counter begins at. When reformatting an existing field, set this above the highest number already in use to avoid duplicate identifiers.
The on-screen label for the Name field, often renamed to something domain specific like Invoice Number or Project Title so users immediately understand it.
- A Text Name on a custom object caps at 80 characters, while standard Account Name allows 255; plan for that if you import long titles.
- Auto Number digit counts are a minimum, not a ceiling: A-{0000} continues at A-10000 after A-9999, so padding only stays uniform up to your planned width.
- When switching a populated field back to Auto Number, set Starting Number higher than the highest existing value or Salesforce will reissue numbers and create duplicates.
- A Text Name is not unique by default, so two records can share the same title; use Auto Number or a separate unique field where uniqueness matters.
Prefer this walkthrough as its own page? How to Record Name in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Record Name.
Hands-on resources to go deeper on Record Name.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is the purpose of the Record Name field on a Salesforce object?
Q2. Which two configurations can a Record Name field use?
Q3. Why might a team choose an auto-number Record Name instead of a text Record Name?
Discussion
Loading discussion…