History Tracking for MDA Objects

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


Kite Id


Kite Date New


Kite Date Old


Kite Value New


Kite Value Old


Kite Location New


Kite Location Old


Kite Date Changed


Kite Value Changed


Kite Location Changed


Changed 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,


‘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.

History tracking needs to be simpler than this.  The burden shouldn’t be on the admin to create such a complicated solution simply to be able to track changes to an object/field.   

Is history tracking on the roadmap?  @minh_phan 

Not as easy as just checking Track History on an object like in Salesforce, but the solution above will work. I’m not sure if this is normal use case that most customer have to solve for but if it is, I would recommend developing a simpler solution. While the above works, it can be pretty complicated if you need to do this on multiple objects and fields. 

@darkknight Yes, History tracking is a part of our roadmap. You would be able to select fields to track data changes over a time period.

Will keep you posted on the release plan.


Thank you


Thank you @pgeorge - it will be great to have this as standard functionality in Gainsight.

Hi @phaneendhar_lingam.

Thanks for sharing the workaround for History Tracking in MDA.

Thank you for the workaround. I do agree with the sentiment that this needs to be easier to setup. Its a fairly common use case I’ve seen multiple times in various organizations. 

@pgeorge  is this going to be available in SFDC edition or just NXT? Ballpark idea of timing?

I have started employing similar solutions noted above...its not ideal and look forward to further product enhancements to make this a built-in feature.

Okay workaround. One limitation is that since it is comparing values, it can’t identified when the field was updated but the value remained unchanged. For instance, if I want CSMs to update a field on the C360 every three months that is a picklist, there could be times when the CSM would select the same value from the picklist for a given customer -- as a result we can’t determine if the fields to be updated or if it was but there was no change. It could be reset with a rule every 3 months but that would be another custom workflow that would need to be in place rather than just have OOTB field history tracking.

@darkknight This would be planned for both SFDC and NXT. We have not added to our sprint yet. Will keep you posted on the timelines

+1 would be great to have this

Hi @john_apple I have included ‘changed date’ field to track when an update was made on a field. 

@pgeorge : Is History tracking coming in the next few releases? Above solutions seems like super overkill.

It would be helpful to have the workaround in Sightline Vault to make it easier to implement 


It is not planned in the next few releases, the team is evaluating the technical possibilities. Once the roadmap is fixed, will share the details. 

Thank you 


@pgeorge Looking forward to seeing it on a release plan!

Yes, History Tracking for all MDA is definitely needed.

Possibly approaching 10 fields history tracking per mda as first go would be great pick. 

@kumaranbcak  @narayanan_s  Thanks for the feedback. Field history is part of our roadmap .

+1 to this! It should be way easier to enable field history.

I have followed the steps and it works pretty well. Added RuleDate as a ChangedDate.

The only missing part is the expression which determines if old not equal to new then True, How do I get to know for which field it is not true like

My expression has below e.g

Old CSM != New CSM

Old TAM != New TAM

Then the boolean expression will tell me only True, But true for which field so I can ingest the new field in History object.


Hi @ShahImran1184, on my side I created a field for each field that I want to track the history. In your case, I would use two separate fields

  1. CSM change
  2. TAM change

Not sure if it is the best way but it it’s a workaround.

Are there any updates for when this feature (field change tracking/history) will be available?

Hello all,


Field level tracking is planned for Q1 2022. You would be able to select fields for a specific object to track data changes over a time period.



Are there any updates here? Are we still looking for this feature to be released in Q1 2022?