Create a field history tracking object using Real Time Rules

  • 24 August 2023
  • 2 replies
  • 190 views
sarahmiracle
Rank
Userlevel 6
Badge +8

I wanted to share how we track key field changes on the Company object using Real Time Rules. This is a common use case that is easy to implement once you get comfortable with Real Time Rule functionality!

Step 1: Create your History Tracking Object

We use a custom object to hold information for our key field changes. We titled it “Company History Tracking.” It has the following fields:

  • Old Value
  • New Value
  • Field
  • Company (GSID lookup)
  • and the other system-generated fields

Step 2: Create your Real Time Rule

Real Time Rules can be used to track field level changes on limited objects (called “Topics”). For this example, we’ll use the “Company” topic to track field level changes from Company in real-time.

Step 3: Choose your event (what do you want to track that changes?)

After choosing your “Topic” (Company), choose your “Event.” This is the change that occurs that will trigger the rule. There are some OOTB options for you, but if you’re looking to do multiple changes at once, use a “Custom Update.”

Step 4: Choose your fields to track that change, and set your filter criteria to OR

Select your fields that you want to track changes on. Set your filter criteria to “OR” so the rule will trigger anytime any of those designated fields are changed.

Note: Because you’ll use filter logic to track any of the fields that changed, you are limited to 26 (filters A-Z). You can always create another real time rule to continue tracking the other Company field changes you might need if they exceed 26.

Step 5: Setup your Actions

You’ll have one action per field that is tracked. So if you have 14 fields you want to track changes on from Company, you’ll have 14 actions -- one action for each load to the custom object for each field.

Your action setup will be as follows (example provided for CSM value change):

  • Insert
  • Old GSID = Company GSID
  • Old CSM = Old Value
  • New CSM = New Value
  • *Custom* CSM = Field
  • Criteria: Old CSM not equal to New CSM

Note that this setup would have the GSID of the user in the Old Value / New Value. Adjust your field fetch and setup accordingly if you’d prefer to track the CSM Name

 

Some fields that we track changes on include:

  • CSM
  • Payment Status
  • Segment
  • External ID values
  • Account Executive
  • Some other custom editable fields on the C360 that CSMs update (like risk tracking details)
Customer Success Systems Admin @ Amplitude, 2x Gainsight CS Ops Product Council Member

2 replies

bradley
Rank
Userlevel 7
Badge +6

Great writeup! We do this as well - some of our fields are end-user editable so we also want additional audit options like when it was changed and who changed it. 

You can tell when it was changed by when the record was created in your custom object, but we also load “New Modified Date” to a custom field “Created Date” on the object.

 

To get who changed the field, we created a custom field on our History object with a User GSID Lookup “Created By”, and in the RTR mapped “New Modified By” to this field. There is an existing system field called “GS Created By” with a user lookup, but that just tells who who made the record in your custom object (System Administrator), not who actually changed the field.

jparker
Rank
Userlevel 3
Badge +3

+1 on the great write-up

We do very similar with a couple of extra things:

  1. The ‘Field’ field is a Dropdown which makes it easier for reporting. Whenever a new field is added to history tracking, we add a new value in the Dropdown
  2. We also use User Before and User After fields so that if any of the changes being tracked are related to User GSID values, our Company History object has direct lookups to the  fields on the User records

Reply


Terms & ConditionsCookie settings