History Tracking for MDA Objects

Related products: CS Rules & Permissions

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.

Adding my +1 to this; there are certain fields I’m tracking history for now using real-time rules, however 1) this is time consuming and really not a scalable approach, 2) only works with a low-volume object and 3) change tracking should really be considered as a standard for an enterprise solution allowing admins to review changes within their instance (this challenge isn’t just limited to MDA changes but across all aspects of the application).

 

From an admin perspective, it’s disappointing to see functionality for change tracking deprioritized versus other functionality.