Show MeStart free

DO ONE THING WELL

Create, Update and Upsert CRM Records

Intermediate4 minNarrated guide

Listen to this guide

English narration. Duration shown in the player.

Read the narration transcript

Create, update, and upsert describe three different intentions. Before selecting an action, decide whether every submission should produce a new record or whether repeated submissions should change the same record. The right choice depends on your process and the connector's supported matching behavior.

Create asks the CRM to add a new record. That can be appropriate for a new request or event registration. Do not assume create checks for duplicates. Repeated submissions may produce separate records unless another confirmed rule prevents that behavior.

Update changes an existing record identified through the connector's supported method. A CRM record identifier is a common choice. Decide what should happen if the target cannot be found. Do not assume an update will create a replacement record.

Upsert normally looks for a match, updates the matched record, or creates one when no match exists. Check the connector's actual rules. If several records match, the process should stop for review rather than choosing an arbitrary person.

Prefer a stable, unique identifier supported by the CRM and connector. For example, a volunteer might have external ID V O L, one zero four two. Names are unreliable matching keys. Email can change, be shared, or appear on several records.

Test with a fictional record. Submit one supported identifier and a sample phone number. Then submit the same identifier with a changed number. For an intended upsert, check that the expected record changed and that an unwanted second record was not created.

If a request times out, inspect the CRM before repeating it. The write may have succeeded even though the response was lost. Keep the submission identifier, record identifier, and delivery result together. Avoid changing the matching rule while investigating the same delivery.

Your next step is to write down the action, matching key, and expected behavior for no match or multiple matches. Test those cases before using customer data. The written Klarstig Academy guide gives you the same decision checklist.

Watch the narrated slides
English audio · on-screen English captions2:17

Music: A Kind Of Hope by Scott Buckley, licensed under CC BY 4.0. Edited for length, fades and background level.

Choose the right write action and a reliable way to identify an existing record.

Choose the right record action

Create, update, and upsert describe three different intentions. Before selecting an action, decide whether every submission should produce a new record or whether repeated submissions should change the same record. The right choice depends on your process and the connector's supported matching behavior.

  • Create a new record
  • Update a known record
  • Match, then update or create

Create

Create asks the CRM to add a new record. That can be appropriate for a new request or event registration. Do not assume create checks for duplicates. Repeated submissions may produce separate records unless another confirmed rule prevents that behavior.

  • Useful for genuinely new items
  • Does not imply duplicate checking
  • Repeated submissions need a policy

Update

Update changes an existing record identified through the connector's supported method. A CRM record identifier is a common choice. Decide what should happen if the target cannot be found. Do not assume an update will create a replacement record.

  • Identify the correct record
  • Choose the fields to change
  • Define the no-match outcome

Upsert

Upsert normally looks for a match, updates the matched record, or creates one when no match exists. Check the connector's actual rules. If several records match, the process should stop for review rather than choosing an arbitrary person.

  • One match → update
  • No match → create, when supported
  • Multiple matches → review

Choose a dependable matching key

Prefer a stable, unique identifier supported by the CRM and connector. For example, a volunteer might have external ID V O L, one zero four two. Names are unreliable matching keys. Email can change, be shared, or appear on several records.

  • Example external ID: VOL-1042
  • Confirm uniqueness in the CRM
  • Check what the connector supports

Test the same identity twice

Test with a fictional record. Submit one supported identifier and a sample phone number. Then submit the same identifier with a changed number. For an intended upsert, check that the expected record changed and that an unwanted second record was not created.

  • First: VOL-1042, phone ending 0101
  • Second: VOL-1042, phone ending 0102
  • Verify the expected record ID

Check ambiguous outcomes

If a request times out, inspect the CRM before repeating it. The write may have succeeded even though the response was lost. Keep the submission identifier, record identifier, and delivery result together. Avoid changing the matching rule while investigating the same delivery.

  • Inspect the CRM before repeating
  • Keep the submission and record IDs
  • Do not switch matching rules mid-retry

Your next step

Your next step is to write down the action, matching key, and expected behavior for no match or multiple matches. Test those cases before using customer data. The written Klarstig Academy guide gives you the same decision checklist.

  • Which action?
  • Which unique key?
  • What if there are zero or many matches?

Examples illustrate decisions and do not report a completed CRM transaction.

Did this help you move forward?

Next guide

CRM Prefill: Plan the Right Data

Need help with this step?

Find an answer, follow a guide or tell us where you’re stuck.

Talk to a person