I’m also eagerly awaiting the MODIFIED_TIME() and Metadata API features!
But for now, here’s how I find changes:
New Records
Store the RECORD_ID() or the CREATED_TIME() for the last record your application requested. Subsequent requests can specify only records created after that record using the filterByFormula parameter.
Example filterByFormula param to get last known record:
RECORD_ID() = "a89ds790sad8f09ds8f90"
Example filterByFormula param to get records after time:
CREATED_TIME() > "2015-11-11T22:18:17"
Formula field reference
For an overview of formula fields, please refer to the Guide to Formula, Lookup, Count, and Rollup fields. Formulas may involve functions, numeric operations, logical operations, and text operation...
Modified Records
The best way I’ve found to handle the identification of modified records is by:
- Identify specific fields to “watch”
- Request as few records as needed using filterByFormula. For example, for an events application I only retrieved upcoming events that were marked as “active”. This means my application won’t be aware of any inactive or past events, but for my application this was sufficient.
- Request as few fields as needed using the fields parameter. This speeds things up.
- Update/Patch only the fields that have actually changed. I’ve found debugging and performance to be improved by comparing each field I’m watching and building a new object/array/record using only the fields that have changed. This prevents the submission of values that have not changed and allows your debugging/console messages to be specific and informative. The alternative would be to create a hash of the entire record and if new_hash != old_hash update the whole record. This isn’t bad, just not the route I went down.
