WEBVTT

1
00:00:00.200 --> 00:00:04.861
When a CRM sync fails, start with the delivery you are investigating.

2
00:00:05.041 --> 00:00:11.119
Repeatedly submitting the form can make the problem
harder to diagnose and may create duplicates.

3
00:00:11.299 --> 00:00:16.877
Keep the submission, connection, and intended
destination together while you review the result.

4
00:00:17.337 --> 00:00:22.200
Open Mappings and logs for the relevant connection in Klarstig.ai.

5
00:00:22.380 --> 00:00:25.293
Locate the delivery and read its specific error.

6
00:00:25.473 --> 00:00:29.654
Keep the request or delivery identifier and the time of the attempt.

7
00:00:29.834 --> 00:00:34.601
These references help an administrator find the corresponding server details.

8
00:00:35.061 --> 00:00:38.847
Authentication and permission errors belong to the connection.

9
00:00:39.027 --> 00:00:43.175
Check the selected account and the permissions required by the action.

10
00:00:43.355 --> 00:00:48.166
Reconnect through the secure flow when access has expired or been revoked.

11
00:00:48.346 --> 00:00:52.484
Changing a field mapping will not repair invalid authorization.

12
00:00:52.944 --> 00:00:56.913
A validation error points to the submitted information or mapping.

13
00:00:57.093 --> 00:01:03.353
Look for a missing required field, an unsupported
dropdown value, or a value in the wrong format.

14
00:01:03.533 --> 00:01:05.689
Confirm the destination object.

15
00:01:05.869 --> 00:01:08.987
Correct the cause before considering another delivery.

16
00:01:09.447 --> 00:01:13.757
A rate limit or temporary provider failure may need time to recover.

17
00:01:13.937 --> 00:01:20.538
A timeout needs extra care because the CRM may
have accepted the write before the response was lost.

18
00:01:20.718 --> 00:01:27.085
Inspect the destination using a reliable identifier
before sending the same information again.

19
00:01:27.545 --> 00:01:31.586
Use the recovery action your implementation actually provides.

20
00:01:31.766 --> 00:01:37.888
Run queued deliveries processes pending work;
it is not a promise to replay every failed run.

21
00:01:38.068 --> 00:01:41.269
A new test or submission creates a separate attempt.

22
00:01:41.449 --> 00:01:44.564
A terminal failure may need administrator review.

23
00:01:45.024 --> 00:01:49.279
Before recovery, confirm which data and mapping the attempt will use.

24
00:01:49.459 --> 00:01:54.258
Changing today's mapping may not change an already queued or recorded run.

25
00:01:54.438 --> 00:02:02.458
Check for an existing CRM record, use the approved recovery
method, and verify the final result in the destination.

26
00:02:02.918 --> 00:02:10.384
Your next step is to keep a short incident note: what failed,
what was corrected, and which record confirms the outcome.

27
00:02:10.564 --> 00:02:17.058
Share the error reference with support when needed, while
keeping tokens and customer details out of the message.

28
00:02:17.238 --> 00:02:20.076
The written guide contains the same checklist.