How Does CS:Govern Work With Snapshotting?
The CopyStorm Snapshotting system is analogous to the old cartoon flip books in which each successive page of the book was slightly different from the one before it. By rapidly flipping through those pages, however, a story is told. Think of a CopyStorm snapshot as being a page in the book – it is a view of the state of your Salesforce data at that point in time that it was created. Viewing the data in succession is like the cartoon flip book – your data evolves over time and those views tell your data story.
All Capstorm products were designed to work together in concert, and accordingly, CS:Govern integrates seemlessly with the CopyStorm snapshotting system. The functionality parallels that of a “normal” CopyStorm database with similarities and differences described in the following table:
| Feature | CopyStorm | Snapshot |
|---|---|---|
| Record Storage | Salesforce Object Table (e.g. Account) | CopyForceArchiveRecord Table. A single XML document contains all the field values for a record. |
| Field Value Location | One-to-one correspondence with Salesforce Object Table column. | XML Tag inside the parent XML document containing all field values. |
| Deleted Record Handling | Depending on deleted record retention settings in the config, records are eventually deleted. If the retention period is zero, the record is immediately deleted. | Field data is NEVER deleted. It would defeat the purpose of having a snapshot in the first place, and would be equivalent to deleting a page in the cartoon flip book. |
| Base64 Handling | Field data is stored as chunks in the CopyForceTableFieldChunk table depending upon whether the Base64 chunking function is enabled in the configuration and whether the Base64 value, in its entirety exceeds the configured maximum chunk size or not. If chunks are created then the field value in the CopyStorm object table is a “pointer” (a JSON snippet containing metadata related to the record in the CopyForceTableFieldChunk table.) | Field data is ALWAYS stored as chunks in the CopyForceArchiveFieldChunk table. The XML field value is a “pointer” (a JSON snippet containing metadata related to the record in the CopyForceArchiveFieldChunk table.) |
| Insertion Policy | Immediate upon executing a CopyStorm session. | NEVER. The CopyStorm database is considered the effective latest snapshot, so storing new records in a snapshot would be redundant. |
| Update Policy | Immediate upon executing a CopyStorm session. | Depending upon the snapshot policy configuration, a new snapshot record will be created in the CopyForceArchiveRecord table either prior to, or after, the update. |
| Location of CS:Govern Field Assignment Masking Rules and Compliance Categories | The CS:Govern database, GuardianFieldAccessCategory and GuardianField tables. | The Snapshot database, CopyForceArchiveFieldSet table. |
The interaction between CS:Govern and the Snapshotting system parallels the interaction it has with the CopyStorm database. CopyStorm is not CS:Govern “aware”, and the Snapshotting system is mostly not aware either. It must be emphasized that in both cases at no point in time are new or updated records with protected fields stored anywhere in a human readable form (aka, unencrypted). That includes the CopyStorm database as well as the Snapshot records XML document. Should CopyStorm, or a running Custodian, mysteriously hang, or should the machine running either CopyStorm or a Custodian, crash, there is no transient state in which processed CopyStorm records, or Snapshot records contain any unencrypted data. For the case of an EncryptFields Custodian crash, the incremental execution of a Custodian guarantees that upon rebooting the system, or restarting CS:Govern, the Custodian will continue where it left off and continue the encryption process on the remaining records. Should a CopyStorm session be running in parallel with any Custodian executing at the same time, all new and updated records in CopyStorm will have their protected fields encrypted.
While Salesforce data is entered into the CopyStorm database, depending upon the CS:Govern field rules, triggers may, behind the scenes, encrypt that data and push masked values into the CopyStorm records, and encrypted values into the associated CS:Govern storage tables. This is how CopyStorm is completely CS:Govern un-aware.
The Snapshotting system is only slightly different from CopyStorm in the sense that the XML data document in a Snapshot record IS the storage medium as well as the holder of unencrypted data. Triggers do not create the Snapshot records – the Snapshot system is responsible for that. The Snapshot system needs to know which records are protected, so that it can intelligently retrieve the encrypted values, which are then stored as a Base64 representation in the XML tag. That is why the Snapshot system is “mostly” CS:Govern un-aware.
The following screenshot is an example of a Snapshot XML document. Notice that it contains non-encrypted data as well as encrypted data along with the masked values for BillingCity and BillingStreet. Encrypted values are stored in the XML document in their Base64 representation.
