The Salesforce shared responsibility model splits duties between Salesforce and its customers. Salesforce secures and runs the platform: the infrastructure, uptime, and application-level security. You, the customer, own everything you put into it. Your data, your metadata, and your configuration are yours to manage, and that includes backing them up and recovering them when something goes wrong.
Most teams assume that because Salesforce is a trusted, enterprise-grade cloud, their data is automatically protected end to end. It is not. Salesforce protects the platform from platform-level failures. It does not protect your records from your own users, your own deployments, or your own integrations. That gap is where data loss happens, and closing it is your job, not Salesforce's.
What is the Salesforce shared responsibility model?
The shared responsibility model is the standard way cloud providers divide security and data duties with their customers. The provider is responsible for the security of the cloud. The customer is responsible for security in the cloud. Salesforce applies the same split: Salesforce keeps the service available, patched, and secure at the platform layer, and you are responsible for the data and configuration you create inside it.
In practice, that means Salesforce will keep the lights on, defend the infrastructure, and maintain the platform's own resilience. It does not mean Salesforce keeps a private, restorable copy of your records that you can roll back to after a bad import or an accidental mass delete. The responsibility for having a clean, recoverable copy of your own data sits with you. <!-- VERIFY: confirm Salesforce Help / Trust wording on customer responsibility for data backup; quote precisely from the current page -->
What does Salesforce protect, and what do you own?
The clearest way to see the model is side by side. Salesforce owns the platform. You own what lives on it.
Read the right-hand column again. Uptime is not the same as backup. Salesforce can keep the service running perfectly and still have no way to give you back the 40,000 records a bad integration overwrote last night, because those records are yours to protect. Platform disaster recovery restores Salesforce; it does not restore your mistakes. <!-- VERIFY: confirm current Salesforce shared-responsibility / trust page wording and URL for this mapping; policy pages change -->
Does Salesforce back up your data for you?
Not in the way most people expect. Salesforce protects the platform and maintains its own infrastructure-level resilience, but it does not keep an on-demand, restorable backup of your individual org's data that you can call on after a data-loss event.
The clearest signal of this came from Salesforce itself. Salesforce retired its paid Data Recovery service, a last-resort option that could take weeks to complete and cost thousands of dollars, and pointed customers toward backing up their own data with a dedicated backup solution. <!-- VERIFY: confirm current Salesforce Help wording/URL. Data Recovery service retired effective 2020-07-31; verify the exact date, that it has not been reinstated in a different form, and current guidance/pricing before publish -->
Salesforce does provide some native tools that people mistake for backup: the weekly data export, the Recycle Bin, and field history tracking. None of them is a true backup and recovery system:
- Weekly/manual data export produces a set of CSV files. It captures data, not the relationships and metadata needed to restore cleanly, and it runs on a limited schedule. Rebuilding an org from raw CSVs by hand is slow and error-prone.
- The Recycle Bin holds deleted records only for a limited retention window before they are purged, and it has a storage cap. It is a short grace period, not a backup. <!-- VERIFY: confirm Recycle Bin retention window (commonly 15 days) and storage limits against current Salesforce Help before publish -->
- Field history tracking logs changes to a limited number of fields for a limited time. It is an audit trail, not a restore point.
If you need to recover a specific state of your data from before an incident, quickly and with relationships intact, none of these gets you there on its own.
What can actually go wrong with Salesforce data?
Platform outages are rarely the thing that loses your data. The common causes are ordinary and internal, which is exactly why the shared responsibility model puts them on you.
- Accidental deletion. A user mass-deletes the wrong list view, an admin runs a delete on the wrong filter, or a merge collapses records that should have stayed separate. Once the Recycle Bin window passes, that data is gone.
- Bad deployments. A release overwrites field values, changes a picklist, or pushes a flawed automation that corrupts records the moment it activates. The deploy succeeded; the data did not survive it.
- Integration and API errors. A misconfigured sync, a duplicate job, or an ETL tool writing to the wrong field can overwrite or wipe thousands of records in minutes, faster than anyone notices.
- Rogue or careless automation. A trigger, flow, or batch job with a logic error updates records at scale before anyone catches it.
- Departing users and insider mistakes. Someone with broad access exports, alters, or deletes data on the way out, or simply makes a large, well-intentioned change that turns out to be wrong.
Every one of these sits on the customer side of the line. Salesforce keeping the platform healthy does nothing to reverse them. What reverses them is your own backup, and a fast, reliable way to restore from it.
Why do you need a real backup and recovery solution?
Because "export a CSV once a week" is not a recovery plan, and the Recycle Bin is not a safety net. The shared responsibility model makes recovery your obligation, so you need a system built to meet it: automated, frequent backups of both data and metadata, and the ability to restore a known-good state quickly and with relationships intact.
This is the functional gap Flosum Backup & Archive is built to close. It provides automated backup of your Salesforce data and metadata, field-level and fast recovery so you can restore what was lost without rebuilding the whole org, and long-term retention and archiving for records you need to keep but not keep live. In short, it gives you the recoverable copy the shared responsibility model says you are responsible for having.
Recovery is also a compliance requirement, not just an operational one. Regulated teams have to prove they can restore data and demonstrate controls over it. For how backup and recovery fit into audit and controls obligations, see SOX compliance for Salesforce. For the full picture of protecting a Salesforce org, start with our Salesforce backup and recovery guide.
Thank you for subscribing
