A Salesforce admin usually discovers data management gaps at the worst moment. A deployment introduces bad records, list views start timing out, and the team scrambles to prove what changed.
Standard Salesforce tools cover basic administration, but they leave clear gaps once data volume, audit pressure and release complexity grow.
This guide covers four areas: data quality, large data volume performance, backup and recovery, and regulatory retention.
Each section turns Salesforce documentation into configuration choices you can act on.
Why do standard Salesforce tools fall short at enterprise scale?
The gaps start with documented platform limits. Three matter most:
- Backup schedules are too infrequent for release-heavy environments
- Configuration history retention is too short for many audit needs
- Native exports are too coarse for targeted restoration
The most consequential limit is backup frequency. Salesforce's native Data Export lets you generate backup files once every 7 days for weekly exports or every 29 days for monthly exports, and Professional and Developer Editions only get the monthly option.
That schedule does not give release workflows a recovery point close to each production change window. Setup Audit Trail creates a second gap: you can download the past 180 days of setup history, and older entries are deleted.
For teams that deploy often, that limits how far back they can trace configuration changes during audits or post-release investigations. Many teams keep metadata in version control for a longer record.
Native exports are also coarse. Data Export delivers a zip archive of CSV files, and the zip is deleted 48 hours after the notification email, so a team that needs field-level restoration after a bad deployment is left rebuilding related records by hand.
How do you build data quality for AI readiness?
Recovery and retention gaps expose what went wrong after a release. Data quality controls prevent those problems at the source, so strengthen them before new automation and AI features go live.
Poor data feeds poor AI. In Salesforce's State of Data and Analytics research, 89% of data and analytics leaders with AI in production said they had seen inaccurate or misleading AI outputs.
In Salesforce environments, that makes validation, deduplication and ownership controls part of release readiness for Agentforce and for any change to automation logic.
Which data quality dimensions should you enforce?
Use a defined quality model to turn abstract goals into enforceable Salesforce controls. The Salesforce Admins team's Agentforce data checkup scores data on accuracy, completeness, consistency, uniqueness, timeliness and relevance.
- Validation rules enforce data standards at the point of entry
- Matching and duplicate rules reduce record inconsistency across objects
- Flow automates cleanup logic, such as standardizing phone number formats
- Reports and dashboards track gaps such as missing contact information
Ownership matters as much as tooling. Set clear data ownership and standards so someone is accountable when quality drifts after a deployment or process change.
Why is deduplication an AI prerequisite?
Treat duplicate management as release-readiness work, not only cleanup. Duplicate records cause confusion for agents and users, and they are harder to unwind after go-live or a data migration.
- Test duplicate prevention during deployment validation when new flows, integrations or agent actions depend on account and contact data.
- Configure matching rules with a fuzzy match on company names and exact matches on fields like phone numbers.
- Build a custom report type with Duplicate Record Sets and Duplicate Record Items to report on duplicates and track cleanup.
- Give users access to both the Duplicate Record Set and Duplicate Record Items objects so they can build and read those reports.
How do you keep large data volumes fast?
Data quality controls protect what goes into Salesforce. Volume controls protect how Salesforce performs once that data scales.
Salesforce calls "large data volume" an elastic term: its LDV guide applies it once you have tens of millions of records, tens of thousands of users, or hundreds of gigabytes of record storage. There is no fixed threshold, but an excessive record count on one object can slow queries, search, list views and reports, and cause more timeouts.
Those symptoms are the signal to add LDV controls before the next major schema or automation release.
How do custom indexes and selectivity thresholds work?
A custom index helps only when filters stay selective under real data volume. This matters during deployments, because a new report filter, Flow query or Apex change can turn an acceptable query into a production bottleneck.
The query optimizer uses a custom index only if the filter matches less than 10% of the first million records and less than 5% of additional records. On a 5 million record table, that means 300,000 records or fewer.
For AND conditions, the optimizer uses the indexes unless one of them returns more than 20% of the object's records. For OR conditions, every field must be indexed, and the indexes are used unless they all return more than 10%.
Check a query with the Query Plan tool before asking for an index. You can create custom indexes through Salesforce Customer Support or by deploying a custom index file through the Metadata API.
When should you use skinny tables and data archiving?
Separate active data from historical data to protect transaction speed. This reduces load on primary objects and lowers the risk that releases slow down user-facing work.
Skinny tables combine frequently used standard and custom fields to avoid joins, and they omit soft-deleted records. Salesforce Support creates them on custom objects and on Account, Contact, Opportunity, Lead and Case, and they help most on tables with millions of records.
Skinny tables carry overhead, and in the wrong context they can degrade performance instead of improving it. Big Objects suit massive historical datasets, with consistent performance from 1 million to 1 billion records.
Archiving inactive records also helps shrink your storage footprint. Put the rules in a written archiving policy so teams know what moves, when, and how to get it back.
How should backup, recovery and compliance work together?
Volume optimization reduces the data footprint, but it does not cover what happens when records must be recovered or kept as regulatory evidence. Design backup architecture and compliance controls together, because retention rules, audit expectations and deletion obligations shape both.
How do you plan backup beyond native limits?
Set recovery targets before choosing backup schedules. Teams need to know how fast they can recover, how much data they can afford to lose, and whether they can restore specific records after a release issue.
The 3-2-1 rule remains a practical baseline, and Salesforce's own backup guide recommends it: three copies of your data, two on different media, and one offsite. With weekly exports, the gap between recovery points can still be 7 days.
Salesforce's admin guidance says to understand the restore steps before you need them, store downloaded backup files securely, and include documents and images to avoid missing references. Write those targets into a backup and recovery strategy the business has signed off.
How do regulations shape Salesforce retention?
Map each regulation to specific Salesforce controls and evidence. That work sets how long teams keep change history and how they handle deletion requests.
- HIPAA: The Security Rule requires audit controls that record and examine activity in systems containing ePHI. In Salesforce, that affects access logging, change tracking and retention for orgs that store health data.
- SOX: Auditors must keep audit workpapers for seven years, and many public companies align financial-data retention with that. For Salesforce teams, that shapes how deployment evidence and configuration-change logs are kept beyond native retention.
- GDPR: Article 17 requires erasure without undue delay when a valid request applies. Define and test deletion workflows so production changes do not break your GDPR compliance processes.
- CCPA: Businesses must respond to deletion requests within 45 calendar days, and the regulations allow an optional two-step process for online requests, where the consumer submits and then separately confirms. Document whichever process you use so service teams delete consistently.
Set retention periods in a written retention policy and confirm exact periods with your compliance team. For the recovery side, see how to restore deleted records, plan for disaster recovery, and compare Salesforce backup solutions.
Salesforce Shield adds Platform Encryption, Event Monitoring and Field Audit Trail, which keeps field-level history for up to 10 years. It helps protect sensitive data and monitor production changes, but Setup Audit Trail history still has its 180-day window.
How does Flosum Backup & Archive fit in?
A durable data management model rests on quality, performance, recovery and auditability. Under the Salesforce shared responsibility model, protecting and recovering the data you put into Salesforce is your job.
Flosum Backup & Archive is built for the backup and retention work this guide describes: automated, scheduled backup of Salesforce data and metadata, point-in-time and field-level recovery, and long-term archiving to meet retention mandates while reclaiming org storage.
You also choose where your backups live. Flosum Backup & Archive can be deployed Salesforce-native, in the Flosum-hosted cloud, or customer-hosted, so backup copies stay in the control domain your security and compliance teams require.
FAQs
Want to see how this works on your own org? Book a personalized demo to see how Flosum can back up your Salesforce data and metadata, restore exactly what a bad release changed, and keep records for as long as your compliance team requires.
Thank you for subscribing
