BETA - This feature is currently still in a beta state and has some known caveats and limitations.
Watch a recent Troubleshooting Webinar conducted by our Customer Success team here - https://www.bedrockdata.com/blog/webinar-troubleshooting-sync
Things to Note:
- Timestamp column displays dates in the GMT timezone (aka "UTC" or "Universal Coordinated Time")
- You will often see blank cells in the Identity column. More on this below.
Generate the Report
Once you are given access to the report, a new button will show up on your Bedrock Data Dashboard that lets you Generate a Transaction Report. The Download button will generate a report spanning the previous 24 hours by default. To manually specify a date range, select the 'Report Start' box to open the date picker. Make your date selection and apply the 'Days Covered' setting to change the time span, if desired.
At this time the report will download as a CSV file to your computer. We plan to have an interface so you can easily sort through the results within your browser instead of in a spreadsheet. But there is a lot of valuable information in this report and here are some tips on how to read and use this information to resolve conflicts.
This column is very important as it will display the value for the field Bedrock is using to identify who the record is and match up with any other records that are the same in our index (i.e. a contacts email address).
Note that you may see that this cell is blank in some cases. For the NOT_INDEXABLE conflict this will often be blank since the latter conflict means we are missing a value for a particular dedupe key so therefore the Identify column will be blank. It can also be blank because often records will retry syncing after the initially failure occurs because of some error that came back from the destination system. These repeat attempts produce these blank rows in this case. We often find hiding the blank rows is a good option when you just want to track down records you know have a value for the dedupe key and have failed to sync for some other reason.
There are five types of Conflict Events and this column will display the type involved for the given record. Below is an overview of each type of Conflict and what it means.
|MISSING_FIELDS||Required fields are missing, so we cannot create the desired record. Simply go to the record in the originating system and add a value for the required field.|
|DUPE_RECORDS||Duplicate records detected. Cannot process the record. Learn how to resolve DUPE RECORD conflicts.|
|NOT_INDEXABLE||Fields required by our dedupe system are missing. Cannot process the record. Add a value to the dedupe key for the record (i.e. email address for a contact) to resolve.|
|CREATE_ERROR||The third party API returned an error when we tried to create a record. Error details will be included in the description column.|
|UPDATE_ERROR||The third party API returned an error when we tried to update a record. Error details will be included in the description column.|
CREATE_ERROR and UPDATE_ERROR Overview
These are the hardest types of conflicts to resolve and often our support team will need to help in troubleshooting the root cases. However, we are trying to generate a library of common errors that appear for this type of event.
We'll be adding to this section over time and if you have any recommendations for errors you are seeing that you'd like to have added to this section, let us know by sending an email to firstname.lastname@example.org. Make sure to include the error message you are seeing within the report.
This will include some of the details about the conflict. For example, if it is a DUPE_RECORD conflict you will find all of the records included in this conflict and where there is more then one record that exists with the dedupe key value. For the CREATE_ERROR and UPDATE_ERROR conflicts you will see the entire API error that was returned to Bedrock by the destination system. As noted above, these can be the hardest types of conflicts to resolve so be sure to review the API Error library if any of these look to be documented as common errors and how to resolve.