Example of Floating of Record Versions
Consider the following scenario:
This scenario assumes that when a record changes its version, its current version is called record_nameversion_name. For example, A1 is used in the following scenario to depict the first version of the record A.
To understand the concept, consider a scenario when there are two records, A and B. The repository to which they belong has a Record Edit Approval rule associated with it. Therefore, records need an approval before getting updated.
Assume that you perform the following activities on the records A and B:
The repository, for example, Customer, has two records, Firstname and Lastname. Firstname is related to Lastname using the CONTAINS relationship. Both Firstname1 and Lastname1 are in the confirmed state.
Set the Business Rule, Record Edit Approval, and modify Lastname1. The modification generates version 2 (Lastname2) for record Lastname. Version 2 is unconfirmed, and it remains so as long as it is waiting for an approval in the workflow. There will be no change on Firstname1.
Import Firstname contains Lastname. While importing, select the Direct Load option. After the import, Firstname’s version is changed to Firstname2, and Lastname’s to Lastname3. The state of both the records is confirmed.
Since Lastname2 was in the unconfirmed state before the creation of Lastname3, Lastname2 is immediately floated to Lastname4, but its state remains unconfirmed. Even if the version changes, the state remains unchanged. This concept is known as floating of record versions.
Lastname4 is related to the record obtained as a result of the current event. In this scenario, the current event is the Import event that created version Firstname2. Lastname4 copies its relationship from Lastname3, and as a result, Lastname4 is related to Lastname2, not Firstname1.