Salesforce objects and fields are the foundation of every Salesforce org. They're how Salesforce stores customer data, opportunity data, support tickets, and the custom data your business cares about. This guide covers what objects and fields actually are, the difference between standard and custom, the 9 field types, the three relationship types (Lookup, Master-Detail, Hierarchical), per-edition limits, and how ISVs use namespaced custom objects when shipping AppExchange managed packages.

Pro Tip

TL;DR: Salesforce objects are database tables, and fields are the columns. Two types of objects: standard (built into Salesforce: Account, Contact, Lead, Opportunity, Case, etc.) and custom (created by admins to model your business). Salesforce supports 9 field types: Text, Number, Date, Checkbox, Picklist, Lookup, Formula, Roll-Up Summary, and a few more. Three relationship types: Lookup (loose), Master-Detail (tight, parent owns child), Hierarchical (self-referencing, User only). Limits: 500 custom objects on Enterprise Edition (2,000 on Unlimited), 500 custom fields per object. ISVs building AppExchange managed packages use namespaced custom objects to prevent name collisions with subscriber orgs.

A Salesforce object is a database table that stores a specific type of record. Each row in the table is one record (one Account, one Contact, one Opportunity). Each column is a field that describes one attribute of the record (Name, Phone, Industry, Amount). Together, objects and fields form the data model of every Salesforce org.

Salesforce objects have built-in capabilities standard databases don't: each record has an audit trail (CreatedBy, LastModifiedBy), a sharing model (who can see this record), validation rules, automation triggers, and a UI rendering layer (record pages, list views). You don't get just a row of data; you get a fully managed record with security, automation, and UI included.

Standard objects use the schema Salesforce ships (you can add custom fields to them but can't remove standard fields). Custom objects use the schema you define. Custom object API names end with __c by convention. Custom field API names also end with __c.

Less common but worth knowing: Currency (with multi-currency support), Phone (with format validation), Email (with validation), URL (clickable link), Auto Number (sequential identifier), Geolocation (latitude + longitude), and Time (without date).

Salesforce supports three primary relationship types between objects. The choice matters because it controls sharing, deletion behavior, and what reports you can build.

Master-Detail is the only relationship type that enables Roll-Up Summary fields on the parent. If you need to sum, count, or average child records on the parent record, you must use Master-Detail (or write Apex).

Most orgs never hit the custom object limit. The constraints that bite first are formula compile size, custom indexes (which control which fields can be filtered efficiently in reports and list views), and field history tracking (limited to 20 fields per object).

For deeper coverage of formula limits specifically, see our salesforce formula field limits guide.

ISVs building managed packages for AppExchange create custom objects that ship as part of the package. The challenge: a subscriber org might already have an object called 'Invoice', and your managed package also wants to install an 'Invoice' object. Salesforce solves this with namespaces.

If your namespace is 'acme' and you create an object called 'Invoice', the customer sees it in their org as acme__Invoice__c. Their existing Invoice object (if they have one) is untouched. Namespace prefixing is automatic for 2GP managed packages. See our 2026 managed packages guide for the full namespacing walkthrough.

Key considerations for ISVs designing custom objects for AppExchange:

• Subscribers can add custom fields to your managed package objects, but those fields live in their org, not yours

• Custom objects in your managed package count against the subscriber's 500-object limit

• Master-Detail relationships in your package are subscriber-overridable; lookups are not

• Sharing rules and Permission Sets in your package install with the package

• All custom object API names must include the namespace prefix once installed

Three paths to create a custom object, each suited to a different builder.

Setup > Object Manager > Create > Custom Object. Define API Name, Label (singular and plural), Record Name field, and the standard set of fields (CreatedBy, Owner, etc.). Click Save. The object is live in the org.

Define the object in XML metadata and deploy via sf project deploy start or any deployment tool. Required for source-controlled development and managed package building.

Describe the data model in natural language; AI-native managed-package generators like Appnigma produce the namespaced custom object metadata, the field definitions, the validation rules, and the Apex triggers that operate on the object. The output ships as a 2GP managed package ready for AppExchange security review.

Pro Tip

Building a managed package with custom objects for AppExchange? Appnigma generates namespaced custom objects, field definitions, and the Apex that operates on them, all from a natural-language prompt. Book a demo.

Salesforce objects are database tables that store records. Each object has fields (columns) and rows (records). Standard objects (Account, Contact, Lead, Opportunity, Case) are built into Salesforce. Custom objects are created by admins to model business-specific data. Each row gets built-in audit trail, sharing model, validation rules, automation triggers, and UI rendering.

Standard objects (Account, Contact, Lead, Opportunity, Case) ship with Salesforce and have the schema Salesforce defines. Custom objects are created by admins to model business-specific data; their API names end with __c. Enterprise Edition supports 500 custom objects; Unlimited Edition supports 2,000.

Enterprise Edition supports 500 custom fields per object. Unlimited Edition supports 800. Each object also has 40 custom relationships, 10 custom indexes, and 2 master-detail relationships. The first practical constraint is usually formula field compile size (15,000 characters compiled) or custom indexes for filtering.

Nine main field types: Text, Number, Date/Date Time, Checkbox (Boolean), Picklist (single or multi-select), Lookup/Master-Detail (relationships), Formula (calculated value), and Roll-Up Summary (aggregate of child records on master-detail). Plus specialized types: Currency, Phone, Email, URL, Auto Number, Geolocation, Time.

Lookup is a loose link: either record can exist without the other, deleting the parent sets the child's lookup to null. Master-Detail is a tight link: the child cannot exist without the master, deleting the master deletes all children, the child inherits the master's sharing. Only Master-Detail enables Roll-Up Summary fields on the parent.

ISVs create custom objects that ship as part of the managed package. Each custom object gets the package's namespace prefix (e.g., acme__Invoice__c). This prevents collisions with subscriber-created objects of the same name. 2GP managed packages auto-apply the namespace prefix. Custom objects in your package count against the subscriber's 500-object limit.

Three paths: 1) Object Manager (Setup > Object Manager > Create > Custom Object) for admin-driven declarative creation. 2) Metadata API for programmatic, source-controlled creation required for managed packages. 3) AI-native generators like Appnigma that produce namespaced custom objects, field definitions, and operating Apex from natural-language prompts for AppExchange distribution.

• Salesforce formula field limits. Per-object limits, compile size, cross-object references.

• Can a formula field be used in a lookup filter?. Restrictions, workarounds, configuration paths.

• The 2026 Salesforce managed packages guide. Namespace prefixing, 1GP vs 2GP, creation workflow.

• What is Dev Hub in a Partner Business Org?. The control plane for scratch orgs and 2GP packaging.

• How to list on Salesforce AppExchange (2026). The full lifecycle for ISVs.

• Salesforce Object Manager documentation

• Salesforce Custom Field Types

• Salesforce Object Relationship documentation

• Salesforce Editions and Limits

• Salesforce ISVforce Guide v66.0 Spring '26 PDF