Salesforce Big Objects masking gets skipped by almost every masking tool on the market, and the reason is structural: Big Objects don't behave like standard sObjects. They're built for storing billions of archived records cheaply, they don't support standard DML in bulk the way Accounts or Contacts do, and most masking platforms were designed around the assumption that every table looks like a normal object. If your org archives case history, event logs, or old transaction records into Big Objects, there's a real chance those records land in every sandbox refresh with names, emails, and account numbers fully intact.
This isn't a theoretical gap. Big Objects were built specifically to hold the data companies didn't want cluttering their primary tables, which in practice means the oldest, most sensitive customer history in the org. Losing track of it in a sandbox is exactly the kind of blind spot a GDPR auditor will find before your security team does.
What Big Objects Actually Store
Big Objects exist for one reason: standard objects hit storage and performance limits long before a company stops needing the data. Salesforce introduced them so orgs could archive years of transactional history, IoT event data, or audit trails without paying for expensive standard object storage or slowing down reports and list views.
In practice, that means Big Objects often hold the exact data GDPR cares about most: historical case interactions, old billing records, archived support tickets, deprecated custom object data that got migrated off before a cleanup project. A financial services org might archive five years of transaction history into a Big Object called Transaction_Archive__b. A telecom might dump old call detail records there. None of it looks urgent day to day, which is precisely why it gets forgotten during masking planning.
Unlike standard objects, Big Objects use an index-based query model. You query them with SOQL, but only on indexed fields, and you can't update or delete records the normal way. Records are typically immutable once written, other than through specific patterns like Async SOQL or a full object recreation. That immutability is a feature for archival integrity. It's a serious problem for anyone trying to mask the data after the fact.
Why Standard Masking Tools Skip Them
Most masking platforms, including a fair number of vendor tools that claim broad Salesforce coverage, work by running DML updates against object fields: update the Contact record, overwrite Email and Phone, move on. Big Objects don't accept that workflow. There's no standard Update() call that rewrites a Big Object record in place the way there is for a Case or an Opportunity.
That single technical fact explains why Big Objects rarely appear in masking scope documents. A tool built to iterate through objects and issue bulk DML simply has nothing to do when it hits a Big Object, so it skips it silently. No error, no warning, just a table full of untouched production data sitting in every sandbox the org spins up.
The second reason is visibility. Admins configuring masking rules typically work from a list of standard and custom objects surfaced in Setup's object manager. Big Objects show up there too, but they're easy to overlook because they're rarely part of day-to-day admin work. Nobody builds a Flow against a Big Object. Nobody adds it to a page layout. It sits quietly in the background until a compliance review asks what's actually in the sandbox.
The GDPR Exposure This Creates
Article 5 of GDPR doesn't carve out an exception for data that's hard to update. If a Big Object contains identifiable customer data and that data ends up in a sandbox accessible to developers, contractors, or an offshore QA team, it's a processing activity like any other, and it needs a lawful basis and appropriate technical safeguards.
The risk compounds because Big Object data tends to be older and more voluminous than what lives in standard objects. A five-year transaction archive might hold ten times the row count of the active Account and Contact tables combined. If that archive includes personal financial detail or health interaction history, a breach in a sandbox environment touches far more data subjects than the same breach against production-scoped standard objects.
There's also a retention angle worth calling out directly. Companies often archive data into Big Objects specifically because they've decided it should be retained for compliance reasons, not because customers requested to keep it. That's a defensible position in production, where access is controlled. It's much harder to defend once that same archived data sits unmasked in a sandbox with looser access controls, longer retention between refreshes, and no audit trail of who queried it.
How to Actually Mask Big Object Data
Because Big Objects can't be updated with standard DML, masking them requires a rebuild-and-replace approach rather than an in-place overwrite. The general pattern looks like this:
- Extract the Big Object records via SOQL, respecting the indexed-field query limits.
- Generate masked replacement values for every PII field, keeping referential consistency where the Big Object links back to standard object IDs.
- Delete the existing Big Object records, which Salesforce does support through a batch delete pattern.
- Reload the masked dataset using the Bulk API's Big Object-specific insert operations.
This is heavier than a standard masking pass, and it's the main reason it gets deprioritized. It requires custom Apex or a masking platform that explicitly supports Big Object read-delete-reload cycles, not just generic sObject field overwrites. Anyone evaluating a masking vendor should ask directly whether Big Objects are in scope, because the sales deck almost never mentions it.
Async SOQL offers a partial alternative for orgs that need to transform Big Object data without a full delete-and-reload, since it can process large volumes and write results elsewhere. In our view this only closes half the gap. It's useful for generating masked exports, but you still need a mechanism to get the masked version back into the Big Object before the sandbox goes live for developers.
Building Big Object Coverage Into the Refresh Pipeline
The fix isn't heroic effort on a one-off basis. It's making Big Object masking a permanent, scheduled step in the refresh pipeline rather than a manual task someone remembers occasionally. That means treating it the same way you'd treat masking rules for Contact or Case: defined once, versioned, and triggered automatically every time a sandbox refreshes.
MaskEzee handles this by scanning the full object model at scan time, Big Objects included, and flagging any indexed field that matches known PII patterns, things like Email__c, SSN__c, or Account_Number__c naming conventions. From there it builds the extract-transform-reload sequence automatically instead of leaving admins to script it by hand. That matters because hand-rolled scripts tend to get skipped under deadline pressure, and a skipped script is functionally the same as no masking at all.
Teams running frequent refresh cycles, weekly or biweekly, especially need this automated because Big Object volumes only grow over time. A dataset that takes twenty minutes to mask today can take two hours in eighteen months, and if the masking step isn't built into the pipeline's scheduling logic, it becomes the bottleneck that gets cut when a refresh runs late.
Auditing What's Already Slipped Through
Before assuming Big Objects are covered, it's worth running a direct check. Pull a list of every Big Object in the org from Setup, cross-reference it against the masking tool's coverage report, and query a sample of records in the current sandbox to see if real names, emails, or IDs show up.
Most orgs running this check for the first time find at least one Big Object that's been silently exempt from masking since it was created. That's not a knock on the admin team. It's a predictable result of a platform feature that was built for storage efficiency and bolted onto a masking ecosystem that wasn't designed with it in mind.
The table below summarizes the practical differences that make Big Objects a distinct masking problem rather than just another object on the list.
| Aspect | Standard Object | Big Object |
|---|---|---|
| Update mechanism | Standard DML (Update) | Delete and reload only |
| Typical masking tool support | Broad, built-in | Rare, needs explicit config |
| Query model | Full SOQL | Indexed fields only |
| Common contents | Active records | Archived history, logs, transactions |
| Typical volume | Thousands to millions | Millions to billions |
None of this makes Big Objects impossible to mask. It makes them a category that needs its own line item in the masking scope document, its own test in the audit checklist, and its own place in the refresh automation rather than an afterthought discovered during a compliance review.
Frequently Asked Questions
Why don't most Salesforce masking tools cover Big Objects?
Big Objects don't support standard DML updates, so tools built around bulk Update() calls have no way to overwrite fields in place. Masking a Big Object requires extracting, transforming, deleting, and reloading the data, which is a different technical pattern than most masking platforms were built around, so vendors often exclude it from scope by default.
Can Big Object data be queried and updated like a standard Salesforce object?
No. Big Objects only support SOQL queries on indexed fields and don't allow standard record updates. Changing existing data typically requires deleting the records through a batch process and reloading a corrected version through the Bulk API.
What kind of PII typically ends up in Big Objects?
Big Objects are commonly used for archived case history, old transaction or billing records, deprecated custom object data, and event or interaction logs. These often contain names, emails, phone numbers, and account or financial identifiers carried over from the original standard object before archiving.
Does GDPR treat Big Object data differently from standard object data?
No. GDPR applies to any personal data regardless of which Salesforce storage mechanism holds it. Archived data in a Big Object still counts as processing personal data if it's identifiable, and it still needs to be masked or protected before it lands in a sandbox environment.
How can admins check if Big Objects are being masked during a sandbox refresh?
Pull the list of Big Objects from Setup, compare it against the masking tool's coverage or scan report, and directly query a sample of records in the refreshed sandbox to see if real customer data is still present. Many teams find at least one unmasked Big Object the first time they run this check.