Smartfield tables are one of the few in CRM that don't have DateAdded and DateChanged. If they were present, it would create several substantial benefits:
The ETL to the DW could use DateChanged so only updated records would need to be copied over. This would translate to a huge performance gain for many organizations. For us, it would save hours on the ETL.
These fields could be used as part of Smartfield processing as a more reliable way to determine if a Smartfield needs to be recalculated (e.g., if the SmartField DateChanged is >= the record it is being updated from, then it can be skipped.
Organization Name (Please enter full organization name) | Mass General Brigham |
Reported Version | 4.0 |
We've developed a global change that handles this for constituent smart fields. Happy to discuss if anyone would like to see it in action.
I too would love to have some date tracking for smart fields. We are resisting the urge to create more smart fields before it's such a hit on performance.
For sites migrating from RE, smart fields are the replacement for summary fields in query/export. As such they are used pretty heavily by end users. As the number of smart fields grows, anything that can be done to make the processing of this area more efficient is critical
Having a change date on smart fields at the constituent level would also be a huge improvement for us when sending smart field data to integrated systems. For example, we populate smart fields to LO via BB's LO Connector CRM customization. In order to only send updates to LO for changed SF values, we have to run global changes to flag records to sync to LO based on other data points that would cause the SF value to change. For revenue/recognition related data points, we still miss sending updates that we cannot find via a selection...like when revenue or recognition moves to a new constituent, etc.