Keepit 10.27.0: Planning Salesforce Restores Without Storage Surprises

Recovering Salesforce data is not only a question of which records can be brought back. A restore can also add files, attachments and embedded images to a production org that may already be close to its storage limits. Keepit’s 10.27.0 platform update, dated 22 October 2026, adds a way to review that impact before a Salesforce restore begins.

The update lets Salesforce administrators inspect document scope and estimated storage impact, then choose whether to include or exclude Files, Attachments and images embedded in rich text fields. Keepit says the preview shows estimates for both data storage and file storage. For Hong Kong organisations that rely on Salesforce for sales, customer service or partner operations, this is a useful addition to recovery planning—but it should be treated as a planning aid, not a substitute for testing.

Why storage needs to be part of restore planning

Salesforce separates data storage from file storage. Records such as accounts, contacts, cases and opportunities consume data storage, while files and attachments are counted in file storage. A recovery job that brings back a large volume of related documents can therefore have a different capacity impact from a records-only restore.

This distinction matters after accidental deletion, a bulk update gone wrong, a migration error or a security incident. The records may be the immediate priority, but the documents attached to those records can be essential to business operations: customer correspondence, contracts, service evidence, quotations and other working material.

Salesforce administrators can review current usage and allocations in Setup under Storage Usage. The available capacity depends on the organisation’s edition and licensed users, so teams should use their own org figures rather than relying on a generic storage estimate. Salesforce also notes that storage calculations are asynchronous, meaning usage figures may not reflect a large import or file change immediately.

What Keepit 10.27.0 adds

Keepit’s 10.27.0 update adds pre-restore storage impact insights for Salesforce. Before committing to a restore job, administrators can review the document scope and estimated impact, and decide whether to include or exclude three types of content:

• Files: documents and other files stored in Salesforce Files.
• Attachments: files attached to records, including legacy Salesforce Classic attachment content.
• Rich text field images: images embedded within Salesforce rich text fields.

The preview provides estimates for data storage and file storage. This gives the administrator a chance to adjust the restore scope before execution, rather than discovering a capacity issue after the job has started.

The feature builds on Keepit 10.26.0, which introduced broader pre-restore job insights such as the number of records selected, total data and file size, available storage in the target environment and indicators of possible restore constraints. Taken together, the two updates make the review before a Salesforce restore more informative.

What the preview does—and does not—tell you

A pre-restore estimate is valuable because it turns an otherwise opaque recovery decision into a more measurable one. It can help teams compare a records-only restore with a broader recovery that includes documents, and decide whether the target environment has enough headroom for the selected scope.

However, an estimate is not a guarantee that every item will restore successfully. Salesforce permissions, object relationships, API behaviour, record dependencies and the target org’s configuration can still affect the outcome. The preview also does not create additional Salesforce capacity, change the organisation’s storage allocation or remove the need to validate the recovered data.

There is also an important distinction between including an attachment in the restore scope and restoring it as a standalone item. Keepit’s Salesforce recovery guidance explains that Salesforce Files can be restored in place, while legacy Attachments cannot be restored individually from the Attachments folder. They can be downloaded and uploaded again, or recovered along with the associated record. Administrators should confirm the applicable recovery path for the content they need.

A practical workflow for Hong Kong Salesforce administrators

1. Define the recovery objective

Start with the business process affected. Is the team recovering a small set of deleted customer records, restoring a group of cases, or rebuilding a larger data set after an incident? Identify the point in time required, the affected objects and whether related records and documents are necessary to make the recovered data usable.

2. Check the target org’s storage position

Review data and file storage separately in Salesforce Setup. Record current usage, allocation and remaining headroom. If the recovery is going into a sandbox, check that sandbox’s capacity and configuration rather than assuming it matches production. Where the organisation is close to its limit, agree whether data clean-up, archiving or a different restore scope is appropriate before proceeding.

3. Use the preview to compare restore scope

Review the estimated data and file storage impact in Keepit before starting the job. Consider whether every file type is required for the immediate recovery. For example, a team may need customer and case records first, while some supporting documents can be recovered in a separate, controlled step. Do not exclude content simply to reduce the estimate if doing so would leave the business process incomplete.

4. Test relationships and attachment handling

Use a sandbox or other approved test environment to validate a representative recovery where practical. Check parent and child record relationships, file ownership, record links and the handling of legacy attachments. A restored record without the right supporting document—or a document that is no longer linked to the intended record—may not meet the recovery objective.

5. Validate after the restore

After the job completes, check the restored record counts, sample important records and verify that expected files and rich text images are present. Confirm that users can access the recovered content with the intended permissions. Recheck Salesforce storage usage, but allow for the platform’s asynchronous storage calculations before treating a displayed figure as final.

Questions to ask during a backup and recovery evaluation

For Hong Kong buyers assessing Salesforce backup, the 10.27.0 update highlights several questions worth including in a proof of concept:

• Can administrators preview record, data and file impact before a restore is committed?
• Can they control the inclusion of Files, Attachments and rich text field images separately?
• How are legacy attachments recovered, and which content can be restored in place?
• Can the supplier demonstrate recovery into both production and sandbox environments?
• What permissions are required, and how are restore actions logged and reviewed?
• Which data centre region will hold the backup, and does that arrangement meet the organisation’s contractual and cross-border data requirements?

These questions are especially relevant where Salesforce supports multiple business units, customer-facing teams or regulated workflows. Recovery procedures should be documented, access to restore functions should be limited to authorised roles, and the business should know who can approve a production restore during an incident.

Make storage visibility part of recovery readiness

Keepit 10.27.0 adds a practical checkpoint to Salesforce recovery: administrators can review estimated data and file storage impact and refine the document scope before starting a restore. That can help reduce avoidable capacity surprises, particularly when a recovery includes a large volume of documents or embedded images.

The best result still depends on preparation. Maintain an accurate view of Salesforce storage, understand the difference between Files and legacy Attachments, test restore scenarios and verify the recovered relationships and permissions. For Hong Kong IT teams, those steps turn a new preview feature into a more disciplined recovery process—one that protects not only the records, but also the documents people need to keep serving customers.