---
schema_version: "1"
id: 286f01013b49c5cb1ece7bf8e8d37dfce8f19c51f796e3f00c71c909a09feb77
title: Recovery and Rollback in B2C Commerce
collection: admin
version: current
locale: en-us
portal_url: https://docs.salesforce.com/admin/current/en-us/cc/264-0-0/b2c_recovery_and_rollback.md
canonical_url: https://help.salesforce.com/s/articleView?id=cc.b2c_recovery_and_rollback.htm&release=264.0.0&type=5
source_site: help.salesforce.com
content_type: documentation
content_hash: c3af7d82a86ac87ea404772e7a743d22bf94ee6e67de15016d950dbe48a7ea6f
description: Detect problems and recover from errors during import and export processes.
products:
  - Commerce
  - B2C Commerce
release: "264"
---
# Recovery and Rollback in B2C Commerce

Detect problems and recover from errors during import and export processes.

## Detecting Job Problems

Use Business Manager to configure a job to send an email to the administrator if it runs for more than a specified period.

Sometimes, jobs experience problems and write log entries, but the problems don't stop the import. If these errors are significant, add processing to your import pipelines to detect and stop the import. It's generally a good practice to check import logs regularly to identify any problems.

## Recovering from Job Problems

Release the job lock before running the job again. To release the lock, you stop and restart the instance. For more information, see the Control Center documentation.

## Recovering from Network Issues

If a job dies because the instance went down, import the feed again. Because the standard import feature commits object by object, you never have a corrupted database.

If a job dies part way through an import, the database contains whatever data was successfully imported and any old data that wasn’t changed or removed. An incomplete catalog import causes the search indexes to be out of sync with the catalog, so the search feature doesn't work as expected.

## Recovering from Data Errors

If there appears to be something wrong with the feed data use one of the following methods:

<table class="slds-table slds-table_bordered slds-max-medium-table_stacked slds-m-bottom_small ">
        <colgroup>
          <col>
          <col>
        </colgroup>
        <thead class="slds-text-title_caps ">
          <tr class="">
            <th scope="col" class="slds-cell-wrap" style="text-align:left;vertical-align:top;" id="d138760e78">Recovery Method</th>
            <th scope="col" class="slds-cell-wrap" style="text-align:left;vertical-align:top;" id="d138760e81">Description</th>
          </tr>
        </thead>
        <tbody>
          <tr class="">
            <td data-label="Recovery Method" class="slds-cell-wrap" style="text-align:left;vertical-align:top;" headers="d138760e78 ">Replicate data from another instance</td>

            <td data-label="Description" class="slds-cell-wrap" style="text-align:left;vertical-align:top;" headers="d138760e81 ">This method is most useful if there’s a problem with
              importing onto production and staging has correct data, you can roll back
              to.</td>

          </tr>
          <tr class="">
            <td data-label="Recovery Method" class="slds-cell-wrap" style="text-align:left;vertical-align:top;" headers="d138760e78 ">Import a new feed produced by the backend system.</td>

            <td data-label="Description" class="slds-cell-wrap" style="text-align:left;vertical-align:top;" headers="d138760e81 ">This method is the most common method for recovery.
              Usually, fix the data in the backend system and generate a new feed.</td>

          </tr>
          <tr class="">
            <td data-label="Recovery Method" class="slds-cell-wrap" style="text-align:left;vertical-align:top;" headers="d138760e78 ">Use data from import feed archives</td>

            <td data-label="Description" class="slds-cell-wrap" style="text-align:left;vertical-align:top;" headers="d138760e81 ">This method is most useful if there’s a problem with
              backend system producing the feed. For this data to be available, set up a
              system for archiving feeds and cleaning up old archived feeds.</td>

          </tr>
          <tr class="">
            <td data-label="Recovery Method" class="slds-cell-wrap" style="text-align:left;vertical-align:top;" headers="d138760e78 ">Use data from regular exports</td>

            <td data-label="Description" class="slds-cell-wrap" style="text-align:left;vertical-align:top;" headers="d138760e81 ">
              <p>This method is most useful for data determined on the production system,
                such as availability or data that you import directly onto production,
                such as price books. For this data to be available, create a job that
                exports the required data.</p>
              <p style="margin-bottom:0;">It's also useful for data that only exists in the Business Manager, not
                the backend system, such as web-specific attributes or URL attributes.
              </p>
            </td>

          </tr>
        </tbody>
      </table>

## Customizing Production Instance Feed Rollback

On a production instance, data replication transfers most data to the instance from staging. However, data that you import frequently, such as inventory data or price data, is sometimes imported directly into production. As with staging, if a job is interrupted for any reason, you can have an incomplete import data and previously existing data in the catalog. For example, an incomplete inventory import can let items be sold that are no longer available.

To make sure you import a full feed or nothing, create a custom pipeline. This pipeline encapsulates the objects for import in a single transaction and commits them at once. However, this approach isn't needed or recommended, as it can be difficult to code and debug correctly.

The size constraints for the commit limit any custom pipeline you create. You can't commit more than 1,000 objects at once. A transaction in B2C Commerce can't modify more than 1,000 objects at once. Also, if you’re modifying all of these objects and someone modifies one of them manually, the commit can fail. If you have more objects in a single commit, the commit is more likely to fail.