Salesforce Contact fields: the standard field reference

The Salesforce Contact — a person associated with an account — carries standard fields for who someone is and how to reach them. Most are self-explanatory; a couple have shapes worth knowing. This covers those, and the full standard-field reference has the table across the core objects.

The compound fields

• Name (Name, compound) — not a single text field. It's a compound over Salutation, FirstName, and LastName, and LastName is required. You'll see the components individually in the API and reports.
• MailingAddress (Address, compound) — same idea: a compound over MailingStreet, MailingCity, MailingState, MailingPostalCode, and MailingCountry. Treating either of these like one plain text field is the usual source of confusion when building automation or an integration.

Relationships

• AccountId (Lookup to Account) — the account this contact belongs to. Note: this is the contact's primary account. If you need a contact related to multiple accounts, that's the separate Contacts to Multiple Accounts feature (the AccountContactRelation object), not this field.
• ReportsToId (Lookup to Contact) — a self-lookup that builds the contact org chart. Point one contact's ReportsToId at their manager and you get the hierarchy.
• OwnerId (Lookup to User) — who owns the contact.

Reachability and context

• Email (Email), Phone (Phone), MobilePhone (Phone) — the contact channels.
• Title (Text), Department (Text) — role context.
• LeadSource (Picklist) — how the contact originated.

One org-shape gotcha: Person Accounts

If your org has Person Accounts enabled (common in B2C), the Account and Contact model changes: a person account is a single record that merges account and contact fields. If you're documenting or building on Contact and something doesn't line up, check whether Person Accounts is on — it changes which fields live where.

The honest catch — this is the standard set, not your Contact

Every field above is in every org. What makes your Contact yours is the custom fields — the preference flags, the marketing-consent picklists, the fields a form tool writes to — plus which standard fields you actually populate. A reference can't describe those; they only exist in your org.

SchemaForce inventories every field on Contact (standard and custom), gives each a plain-language description, and shows usage and who can read it — which matters most on Contact, where the personal data lives. So "what's on our Contact object and who can see it" becomes a lookup, not tribal knowledge.