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
Clicking on 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. Note that the days covered is a go forward setting. So for example, if you want to see results from April 10th to April 15th you would set the date to April 10th and select 5 days from the "Days Covered" drop down.
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).
Why is the Identity Column sometimes blank?
In some cases you'll find that this column is blank. 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 records will retry syncing after the initial failure occurs. 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 most difficult conflicts to resolve and often our support team will need to help in troubleshooting the root cases. However, we are building a library of common API errors that will pop up for some of our more popular Connectors. Check out the API Errors section here.
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.