What a snapshot actually holds
A capture covers your records, your files, and the Salesforce metadata types your org exposes. Coverage is defined by your org and your configured scope, not by a fixed list we publish, so this page explains how the scope is derived, and where it ends.
Records
Every object your org can query
The object picker is built from your org's own describeGlobal: every sObject Salesforce reports as queryable and not deprecated. Back up all of them, or name the ones you care about with a WHERE filter each.
- Standard and custom objects, including custom settings and the big-object-adjacent data your org exposes as queryable.
- Field history objects, so "what did this field say in March?" survives Salesforce's own retention window.
- A handful of system objects Salesforce does not support extracting are skipped by the engine rather than failing the run.
Files
Binary content, not just its metadata row
File bodies are downloaded and stored alongside the records that reference them, so a restore rebuilds the attachment, not a dangling pointer.
- Salesforce Files (ContentVersion and ContentDocument), including the current version of each document.
- Classic Attachments and Documents, with the record each belongs to.
- Static resources captured by the Change Tracker, downloadable byte for byte.
Metadata
The types your org exposes, in your tracker's scope
The Change Tracker describes your org in one describeMetadata call and lists every metadata type that org exposes, often more than a hundred. You choose exactly what is in scope, starting from a recommended set.
- Opens on a recommended set: code, schema, automation, security and the folder-based presentation types.
- Add or remove types from your org's live list rather than a fixed menu, and see the scope on the tracker.
- Folder-based types (Reports, Dashboards, Email Templates, Documents) are captured by walking their folders.
Derived from your org, not from our roadmap
There is no universal list of Salesforce metadata. Two orgs on the same release expose different sets, so coverage has to be resolved per org, per run.
Your org publishes its own list
Salesforce reports which metadata types an org exposes, and it differs by edition, enabled features, and release. bluefactory reads that list live instead of hard-coding one, so a type your org gains next release shows up without waiting on us.
You set the scope, once
Track everything (the default), track everything except a few top-level types, or track only the types you name. The choice is stored on the tracker and enforced by the capture engine on every run.
Containers bring their children
Picking CustomObject pulls in its fields, validation rules, list views, and record types: the engine captures decomposed child types through their container, so a narrowed scope keeps field-level history.
Each build stores the whole snapshot
A run captures the full state of everything in scope, not a diff against the last one. Changes are computed between two complete snapshots, so history never depends on replaying a chain.
The types most orgs see tracked
Connect an org and the picker shows the actual list that org exposes, usually well past a hundred types, including ones not named here.
Schema
Code
Automation
Security
User interface
Folder-based
Where coverage ends
Stated up front, because a backup you misunderstand is worse than one you do not have.
Types Salesforce does not expose
If the Metadata API does not support a type for your org and edition, nothing can capture it, bluefactory included. Salesforce publishes a metadata coverage report; that document, not a vendor claim, is the ceiling.
Exclusions are top-level only
You exclude a container such as CustomObject, not one of its children. Child types are captured through their parent, so naming a child in an exclude list has no effect.
History starts when tracking does
The Change Tracker records changes between the builds it captured. The first build is a baseline with no diffs, and nothing before it can be reconstructed.
Per-file fetch caps
File-heavy objects are capped per run, 20,000 files each by default, so one object cannot stall a backup. The cap is visible and adjustable in the backup's advanced settings.
Scoped backups capture what you scoped
If a backup names specific objects or carries WHERE filters, the snapshot holds that slice, and every module reading it sees the same slice. The run's detail page lists exactly what it captured.
Record counts are approximate
Object counts in pickers come from Salesforce's own periodic record-count resource and exist only for a subset of objects. Captured counts on a finished run are exact.
If a type matters to your audit, ask before you buy
Do not take the list on faith
Every finished capture is inspectable. You can read what a run holds before you ever need to restore from it, which is the only way to know a backup is real.
Browse the metadata a build captured
The Change Tracker's metadata browser lists every component in the snapshot, grouped by type, with its source.
Change TrackerQuery the records a backup captured
The Query Console runs SQL over a snapshot: count rows per object, check a field, export the answer.
Query ConsoleRead the storage and retention controls
Where the data lives, who can reach it, and what bluefactory never does with it.
Security
See it on your own org
Add an org and bluefactory lists exactly what it exposes, before you commit to anything.
Free for one org, no credit card.