Block Field Updates Service Issue
As a result of a bug in the 2020 July release, customers may notice updates in data written to fields that have been blocked when the update was made through Web Service API. The bug allowed for an update through API where a “Change Data Value” Activity was generated, and the Source was “Web service API”. Please note that “Block Updates” from all other sources other than Web Service API continued to function as expected.
How to find the affected leads?
To locate the affected leads, you can create a smartlist like in the screenshot below. In this example, let’s assume the “Last Name” field was configured to “Block Updates” from Web service API during the affected period so technically, the system shouldn’t have allowed an update. Due to the bug, update was allowed, and a change could have been possible by API where a “Change Data Value” Activity was generated, and the Source was “Web service API”.
Please also note that there is a 2nd filter “Not Data Value Changed” after the affected period. This implies that the change was most likely valid since it’s from an allowed source after the bug was fixed and there is probably no reason to change the value back to the original prior to the API update. However, individual customer use case may vary and if this doesn’t apply to you, then you can remove this filter.
If you have other fields that were not supposed to be updated via API, you can create a similar smartlist targeting those fields.
How to correct the affected leads field values?
If you have the original values of these fields in your CRM system or other data sources, you can retrieve the values from other system and list import the corrected values back into Marketo.
If the original data doesn’t exist in any other systems, then you would need to rely on the “Change Data Value” that was generated. In the screenshot below, the correct value would be the “Old Value” of the Change Data Value Activity.
Depending on the number of affected leads and what you would consider to be the correct field value, each customer may approach the fix-up differently. Below is a general guideline and it may or may not fit your use case.
You can consider using Bulk Export Activities specifying the affected datetime range and activityTypeId=13 where 13 is “Change Data Value” (CDV). After the export is done, you will need to further filter out the results using the following export fields.
- “primaryAttributeValueId” contains the unique id of the field. The id can be found using /rest/v1/leads/describe.json and you should only fixup the affected field ids.
- “attributes” contains the Source, Old Value and New Value. Specifically, you are looking for a source of “Web service API” and the Old Value was the original value
Alternatively, you can also use our Batch Get Activities API call to retrieve the same data.
Please note that the Retention Policy for “Change Data Value” Activities is 90 days and we advise exporting the activities as soon as possible. The fix-up itself cannot be done sooner.
Below are some cases to take into the consideration when determining the winning field value. Since each customer’s use case may vary, not all cases may apply to you.
- The latest update of a field could be from a valid source. In this case, the value probably would not need to be updated again.
- A lead could have been updated multiple times by Web Service API during the affected period. In such case, the oldest activity’s old value would probably be the right value.
- A lead could have their field value updated by a valid source during the affected period in between 2 API updates. For example,
- 8/1 - Last Name updated from “A” to “B” via Web Service API
- 8/2 – Last Name updated from “B” to “C” via a Valid Source
- 8/3 – Last Name updated from “C” to “D” via Web Service API
In such case, “C” may be the correct value.
.png)