History tracking data is important for trend analysis/ forecasting. But, there could be some objects where we are required to maintain just the snapshot data. For example in standard objects like Company/ User or any custom objects – In Company, when did the CSM change or what was the previous ARR?
As of today, we do not have the luxury of keeping historic changes in Gainsight but with the help of rules/ objects we can still accomplish this.
For demonstration – I’ve created the object ‘Kite Info’, which is loaded around 7am daily.
Schema as follows,
{*Kite Id(String); Kite Name(String); Kite Date (Date); Kite Value (Number); Kite Location (String) }
*Kite Id is the identifier field.
I’ve created a backup object that has only those fields which require history tracking(along with the Identifier) – ‘Kite Info Bkp’. This object is loaded 10am daily.
But, for the first time – data from ‘Kite Info’ is loaded once ‘Kite Info Bkp’ is created.
{*Kite Id(String); Kite Date (Date) ; Kite Value (Number); Kite Location (String) }
*Kite Name is consistent hence not required for tracking.
Rule Name -> ‘Load Kite Info Backup’, scheduled to run at 10am
Load all the values from ‘Kite Info’ to ‘Kite Info Bkp’ with Upsert operation and Identifier ‘Kite Id’
History Tracking object – ‘Kite Info History’
| Column Name | DataType |
| Kite Id | String |
| Kite Date New | Date |
| Kite Date Old | Date |
| Kite Value New | Number |
| Kite Value Old | Number |
| Kite Location New | String |
| Kite Location Old | String |
| Kite Date Changed | Boolean |
| Kite Value Changed | Boolean |
| Kite Location Changed | Boolean |
| Changed Date | Date |
History Tracking Rule Setup,
Rule Name à ‘Kite History Tracking’ ; Scheduled to run at 9am daily.
“Timing of this rule is of highest importance – this should be scheduled to run after the source ‘Kite Info’ is reloaded but before the backup object ‘Kite Info Backup’ is refreshed.
In the Merge task, I’m doing inner join on Kite Id.
Fields in the Transformation task ‘Change Capture’ are as follows,
- Those with prefix ‘new’ are from ‘Kite Info’
- Those with prefix ‘old’ are from ‘Kite Info Bkp’
Field List – Kite Id, Kite Date Old, Kite Date New, Kite Date Changed and similarly for Kite Value and Kite Location
Case statement,
When ‘Kite Value New’ not equals ‘Kite Value Old’ then ‘Kite Value Changed’ is True
Similarly for Kite Date and Kite Location.
I’m introducing another case field as,
When
‘Kite Value New’ not equals ‘Kite Value Old’ (OR)
‘Kite Date New’ not equals ‘Kite Date Old’ (OR)
‘Kite Location New’ not equals ‘Kite Location Old’
Then ‘Changes Made’ is True
Only if the above value true, a record will be considered for inserting into History tracking object.
Loading into History Tracking object is of INSERT type action, as we have to capture all the changes being done.