Big Objects

Why Big Objects Matter

Every Salesforce org eventually hits a wall with data volume. Field history, login events, IoT sensor readings, transaction logs, archived cases and closed opportunities from years ago all pile up. Storing hundreds of millions of these records in standard or custom objects is expensive (data storage is purchased per MB), slows down reports and list views, degrades SOQL performance, and creates data skew and ownership skew problems. At the same time, compliance regulations often require that this historical data be retained for many years and remain queryable on the platform.

Big Objects were built to solve exactly this problem. They let you keep massive volumes of data inside Salesforce, with consistent performance regardless of scale, without paying standard data storage prices and without the overhead of the full declarative automation stack. For the Advanced Administrator exam, Big Objects sit in the Advanced Data and Analytics Management domain, and you are expected to know when to recommend them, how they are structured, how they differ from other storage options, and what their limitations are.

What Is a Big Object?

A Big Object is a Salesforce object type designed to store and manage billions of records natively on the Lightning Platform. Unlike standard and custom objects, Big Objects are built on a horizontally scalable, non-relational storage layer. They deliver consistent performance whether you have one million or one billion records, but in exchange they give up most of the features you associate with regular objects (triggers, flows, reports, sharing rules, and the standard record UI).

There are two categories:

1. Standard Big Objects - Defined by Salesforce and included with specific products. The most important example is FieldHistoryArchive, which is part of the Field Audit Trail add-on and stores archived field history data for up to 10 years (for up to 60 tracked fields per object).

2. Custom Big Objects - Defined by you, either in Setup (Setup > Integrations > Big Objects) or through the Metadata API. Custom Big Objects always carry the __b API name suffix (compared to __c for custom objects and __x for external objects).

Common Use Cases

Salesforce groups Big Object use cases into three themes, and exam scenarios almost always map to one of them:

- 360-degree view of the customer: Extending your data model with high-volume engagement data such as e-commerce clicks, loyalty transactions, billing line items or device telemetry, so it can be related back to Accounts and Contacts.
- Auditing and tracking: Keeping a long-term record of user activity, logins, or field changes for compliance, analytics, or security review.
- Historical archive: Moving old transactional records (closed cases, aged tasks, legacy orders) out of standard objects so day-to-day performance improves while the data remains accessible on the platform.

How Big Objects Work

1. Definition and Deployment
You define a custom Big Object by giving it a label, API name, a set of fields, and an index. While the object has the status In Development you can edit it freely. Once you deploy it, the index becomes locked: you cannot add, remove, or reorder index fields. If you need a different index, you must create a new Big Object and migrate the data. This makes careful upfront design one of the most important aspects of working with Big Objects, and it is a frequent exam theme.

2. Supported Field Types
Big Objects support a deliberately limited set of field types: Text, Long Text Area, Number, Date, Date/Time, Email, Phone, URL, and Lookup relationships (to standard or custom objects). They do not support formula fields, roll-up summary fields, picklists, checkboxes, currency, percent, auto-number, geolocation, rich text, encrypted fields, or master-detail relationships. If a question describes a requirement that depends on a picklist or formula on the archived data, that is a signal Big Objects alone will not satisfy it.

3. The Index
The index is the heart of a Big Object. It is a composite index of up to five fields, and it serves two purposes:
- It defines the uniqueness of a record. Two records with identical values across all index fields are considered the same record. Inserting a record that matches an existing index is treated as an upsert: the existing record is overwritten rather than duplicated. This means a Big Object cannot contain duplicate records by definition.
- It defines the query path. Records are physically ordered by the index fields in the order you specify, so the index dictates which queries are efficient (and even possible).

Rules to remember: index fields must be marked Required; Long Text Area fields cannot be indexed; the order of fields in the index matters enormously; and the index cannot be modified after deployment. A typical design puts the most selective or most commonly filtered field (for example, a Lookup to Account) first, followed by a Date/Time field to support range queries.

4. Loading Data
You cannot create Big Object records through the standard New button. Data is populated through:
- Bulk API (the recommended method for very large loads)
- SOAP and REST APIs
- Apex, using Database.insertImmediate() rather than the standard insert DML
- Data Loader and other ETL tools that use the Bulk API

Note the word Immediate. Big Object inserts are not transactional: they are committed immediately and are not rolled back if the surrounding Apex transaction fails. Similarly, deletion is done with Database.deleteImmediate() in Apex (records are identified by their index values). There is no Recycle Bin for Big Object records, no mass delete via the UI, and no truncate option.

5. Querying Data
Big Objects are queried with SOQL, but with important restrictions that flow directly from the index:
- You can only filter on index fields, and you must filter them in index order without skipping any. If the index is Account, Date, Type, you can filter on Account alone, or Account and Date, but not on Date alone or Account and Type.
- Supported operators are =, <, >, <=, >=, and IN. Operators such as LIKE, !=, NOT IN, INCLUDES, and EXCLUDES are not supported.
- Range operators (<, >, <=, >=) and IN can only be used on the last field in your filter; all preceding index fields must use equality.
- You cannot use aggregate functions, GROUP BY, or standard ORDER BY on non-index fields in the way you would with a custom object.
Historically, Salesforce offered Async SOQL (a pilot feature) to run long-running queries against Big Objects and write results to a custom object for reporting. Async SOQL has since been retired, but older exam material and study guides may still reference it as the path for large-scale or filtered extraction.

6. Security and Access
Big Objects support object-level permissions (Read, Create, Delete) and field-level security through profiles and permission sets. They do not support record-level sharing: there is no OWD setting, no sharing rules, no role hierarchy access, no owner field, and no manual sharing. If a user can read the object, they can read all of its records. This is a critical point for scenario questions involving sensitive archived data.

7. Viewing Data in the UI
Custom Big Objects do not get standard tabs, list views, record detail pages, or related lists. To surface the data for users you must build a custom Lightning Web Component, Aura component, or Visualforce page that queries the Big Object and displays the results. Big Objects are also not available in standard Reports and Dashboards. If reporting is required, the usual pattern is to extract the relevant subset into a custom object (or an external analytics tool such as CRM Analytics via dataflows or an ETL process) and report there.

8. Limits
- Up to 100 custom Big Objects per org.
- Each Big Object can hold billions of records, but the org-wide storage allowance for Big Object records is limited. Orgs receive a baseline allocation (historically one million records) and must purchase additional Big Object capacity add-ons for more.
- Big Object records do not count against standard data storage, which is one of their main cost advantages.
- Field Audit Trail: up to 60 fields tracked per object, with retention policies of up to 10 years.

What Big Objects Do NOT Support (Memorize This List)

- Triggers, Flows, Process Builder, Workflow Rules, Approval Processes
- Validation rules (other than Required on index fields)
- Formula and roll-up summary fields, picklists, checkboxes
- Standard Reports and Dashboards
- Sharing rules, OWD, roles, manual sharing, ownership
- Field history tracking on the Big Object itself
- Standard tabs, list views, record pages, Search (SOSL)
- Duplicate records (identical index values upsert)
- Transactional DML (uses insertImmediate / deleteImmediate)
- Changes to the index after deployment
- Conversion to or from a custom object

Big Objects Compared With the Alternatives

The exam loves to test whether you can pick the right storage mechanism. Keep this comparison in mind:

- Custom Object (__c): Full platform features (automation, reporting, sharing, UI). Best for active, transactional, moderate-volume data. Consumes standard data storage.
- Big Object (__b): Billions of records, stored on-platform, cheap, consistent performance, limited features. Best for archive, audit, and high-volume historical data that must stay in Salesforce but does not need automation or standard reports.
- External Object (__x) via Salesforce Connect: Data stays in an external system and is accessed in real time via OData or Apex adapters. Best when another system is the source of truth and you do not want to copy data into Salesforce.
- Field Audit Trail (FieldHistoryArchive): A standard Big Object for retaining field history beyond the default 18 to 24 months, up to 10 years, driven by HistoryRetentionPolicy metadata.
- Data Cloud / data warehouse / Heroku: Off-platform or separate-platform options for analytics across many sources; not the answer when the question says data must remain on the core Salesforce platform.

Exam Tips: Answering Questions on Big Objects

Tip 1 - Spot the trigger words. When a scenario mentions billions of records, massive volume, historical archive, retain for compliance, seven or ten years, consistent performance at scale, or data must stay on the Salesforce platform but not in a custom object, Big Objects are almost certainly the intended answer.

Tip 2 - Spot the disqualifiers. If the scenario requires triggers, Flow automation, standard reports or dashboards, sharing rules or record-level security, picklists or formula fields, or users editing records in the standard UI, then Big Objects are the wrong answer and you should look for a custom object (or a hybrid: archive to a Big Object and keep a summarized subset in a custom object for reporting).

Tip 3 - Big Object vs External Object. Ask yourself where the data lives. If it is stored in Salesforce, it is a Big Object. If it stays in an external system and is accessed live, it is an External Object via Salesforce Connect. The __b versus __x suffix is a quick giveaway in answer choices.

Tip 4 - Know the index cold. Expect questions on: a maximum of five index fields; index fields must be required; order matters for both uniqueness and querying; the index cannot be changed after deployment; identical index values result in an overwrite, not a duplicate. If a question asks why a load produced fewer records than expected, the answer is usually duplicate index values being upserted.

Tip 5 - Know the query rules. Filter only on index fields, in order, without gaps; equality on all but the last filtered field; range or IN only on the last; no LIKE, no !=. If an answer option queries a non-index field or skips an index field, eliminate it.

Tip 6 - Know how data gets in and out. In: Bulk API, REST/SOAP API, Data Loader, Apex insertImmediate(). Out: SOQL (with restrictions) and custom LWC/Visualforce for display. Delete: Apex deleteImmediate(). There is no standard New button, no Recycle Bin, and no mass delete wizard.

Tip 7 - Remember the security model. Object permissions and field-level security only. No OWD, no sharing rules, no owner. If the question requires that users only see archived records for their own region, Big Objects alone cannot enforce it; you would need to control access at the object level or filter in the custom component.

Tip 8 - Field Audit Trail is a Big Object question in disguise. If the scenario is about retaining field history for longer than the default period (up to 10 years) for compliance, the answer involves Field Audit Trail and the FieldHistoryArchive standard Big Object, configured via a HistoryRetentionPolicy. Remember the 60 fields per object limit.

Tip 9 - Watch for the cost angle. Big Object records do not consume standard data storage, so when the scenario emphasizes reducing data storage costs while keeping historical records accessible, Big Objects beat buying more storage or keeping everything in custom objects.

Tip 10 - Think hybrid when reporting is needed. A classic correct answer is: store the full history in a Big Object, and periodically load a summarized or filtered subset into a custom object (or an analytics platform) for reporting. Do not pick an answer that claims Big Objects can be reported on directly with standard report types.

Tip 11 - Supported field types. Memorize the allowed list: Text, Long Text Area, Number, Date, Date/Time, Email, Phone, URL, Lookup. Anything else in an answer choice (picklist, checkbox, formula, currency, master-detail) is a distractor.

Tip 12 - Plan first, deploy once. Any question about best practice or what should the administrator do first regarding Big Objects usually points to designing the index carefully based on how the data will be queried, because the index is permanent once deployed.

Quick Recap

Big Objects let you store billions of records on the Salesforce platform with consistent performance and without consuming standard data storage. They are defined with a locked composite index of up to five required fields that controls uniqueness and query access. They are loaded via APIs or Apex insertImmediate, queried with restricted SOQL, secured only at the object and field level, and surfaced through custom components rather than standard UI or reports. Use them for archives, audit trails, and high-volume customer data; use custom objects for active, automated, reportable data; and use External Objects when the data should remain outside Salesforce. Master these distinctions and the index and query rules, and Big Object questions on the Advanced Administrator exam become some of the most predictable points you can earn.