Guidelines for Schema changes in Salesforce organization to prevent restore failures
Schema mismatches can lead to restore failures, particularly when recovery points were created before schema changes. To minimize issues, follow these guidelines when modifying the schema in the Salesforce organization.
Table:
Schema change | Description |
|---|---|
Field size change | Widening a field size (for example, from 30 to 60 characters) ensures compatibility with older recovery points. Data from these recovery points can be restored seamlessly. For example, an older recovery point created with an Object Field size of 30 characters can easily restore data to a Field modified to 60 characters. However, it will fail if the Field is truncated to 15 characters. |
Field type change | Changing a field to a compatible type (for example, from Text to TextArea) allows proper restores, as both store string data. However, Cohesity Alta SaaS Protection does not support changing a field to an incompatible type (for example, from Text to Number), which will result in restore failures. |
Deletion of fields | Avoid deleting existing fields of an object, as recovery points rely on the schema captured during the backup process. If a field present in an older recovery point has been deleted in the Salesforce organization, restores will fail. Cohesity Alta SaaS Protection does not currently support restoring data to a schema where fields from the recovery point are missing at the time of restore in target organization. |
Non-Null fields added later | Adding non-null fields to an object after a recovery point has been created is not currently supported for restores from those older recovery points. This functionality is planned for future product updates. |
Picklist and Record Type modifications |
|