WEBVTT

1
00:00:00.200 --> 00:00:04.241
Create, update, and upsert describe three different intentions.

2
00:00:04.421 --> 00:00:13.049
Before selecting an action, decide whether every submission should produce a
new record or whether repeated submissions should change the same record.

3
00:00:13.229 --> 00:00:18.211
The right choice depends on your process and
the connector's supported matching behavior.

4
00:00:18.671 --> 00:00:21.648
Create asks the CRM to add a new record.

5
00:00:21.828 --> 00:00:25.647
That can be appropriate for a new request or event registration.

6
00:00:25.827 --> 00:00:28.422
Do not assume create checks for duplicates.

7
00:00:28.602 --> 00:00:34.821
Repeated submissions may produce separate records
unless another confirmed rule prevents that behavior.

8
00:00:35.281 --> 00:00:40.549
Update changes an existing record identified through the connector's supported method.

9
00:00:40.729 --> 00:00:44.259
A CRM record identifier is a common choice.

10
00:00:44.439 --> 00:00:47.618
Decide what should happen if the target cannot be found.

11
00:00:47.798 --> 00:00:51.182
Do not assume an update will create a replacement record.

12
00:00:51.642 --> 00:00:57.677
Upsert normally looks for a match, updates the
matched record, or creates one when no match exists.

13
00:00:57.857 --> 00:00:59.981
Check the connector's actual rules.

14
00:01:00.161 --> 00:01:06.091
If several records match, the process should stop
for review rather than choosing an arbitrary person.

15
00:01:06.551 --> 00:01:11.756
Prefer a stable, unique identifier supported by the CRM and connector.

16
00:01:11.936 --> 00:01:17.483
For example, a volunteer might have external ID V O L, one zero four two.

17
00:01:17.663 --> 00:01:20.106
Names are unreliable matching keys.

18
00:01:20.286 --> 00:01:24.016
Email can change, be shared, or appear on several records.

19
00:01:24.476 --> 00:01:26.304
Test with a fictional record.

20
00:01:26.484 --> 00:01:30.218
Submit one supported identifier and a sample phone number.

21
00:01:30.398 --> 00:01:33.898
Then submit the same identifier with a changed number.

22
00:01:34.078 --> 00:01:41.352
For an intended upsert, check that the expected record
changed and that an unwanted second record was not created.

23
00:01:41.812 --> 00:01:45.983
If a request times out, inspect the CRM before repeating it.

24
00:01:46.163 --> 00:01:49.576
The write may have succeeded even though the response was lost.

25
00:01:49.756 --> 00:01:55.088
Keep the submission identifier, record identifier, and delivery result together.

26
00:01:55.268 --> 00:01:59.706
Avoid changing the matching rule while investigating the same delivery.

27
00:02:00.166 --> 00:02:07.419
Your next step is to write down the action, matching key,
and expected behavior for no match or multiple matches.

28
00:02:07.599 --> 00:02:10.599
Test those cases before using customer data.

29
00:02:10.779 --> 00:02:15.866
The written Klarstig.ai Academy guide gives you the same decision checklist.