Customer updates
Lesson 10 of 12 7 min read
Create and update WooCommerce customers from your other systems, flag credit-account customers on the storefront, and protect details customers maintain themselves.
Trade businesses often keep their customer list in an inventory system such as Unleashed and want those customers to be able to log in to the store. The Customer Update Document type writes customers into WooCommerce. In this lesson you'll decide whether it creates customers, updates them, or both; how payment terms appear on the storefront; and which details it must never overwrite.
Decision 1: create, update, or both?
| createEnabled | Default true. When true, a customer who doesn't exist in WooCommerce yet is created. When false, they are skipped. |
|---|---|
| updateEnabled | Default true. When true, a customer who already exists in WooCommerce is updated. When false, existing customers are left untouched. |
| usernameIdentifierTypeId | The identifier type used to match WooCommerce usernames to Parties, so customers can be identified and updated by username. |
- Store accounts set up by your team in the inventory system? Leave both on.
- Customers register themselves and you only want to keep them in step? Turn
createEnabledoff. - Only want new accounts, never changes? Turn
updateEnabledoff.
Decision 2: should payment terms show on the storefront?
Some stores let credit-account customers check out "on account" while everyone else pays up front. A plugin decides this by reading a field on the WooCommerce customer. Supply Lens can write that field from the customer's payment term.
| subscriptionMetadataKey | The WooCommerce customer metadata field written from the payment term. This switches the whole feature on: if it's empty, no metadata is sent, whatever the term lists hold. |
|---|---|
| subscriptionIdentifierTypeId | The identifier whose value is written for a credit-term customer. Defaults to the Unleashed customer code (unleashed-customer-code) if not set. |
| creditPaymentTerms | Payment terms that count as credit, for example 30 Days. These customers have their identifier written to the field. |
| upfrontPaymentTerms | Payment terms that count as pay up front. These customers have the field cleared to an empty value. |
How the outcomes work:
- Term in
creditPaymentTerms: the identifier is written. If the identifier can't be found, no metadata is sent at all, because an empty value would make them look like an up-front customer. - Term in
upfrontPaymentTerms: the field is sent empty. - Term in neither list, or no term at all: nothing is sent, so a value set by hand on the site is never overwritten.
- Term in both lists: treated as credit.
- Terms are matched ignoring letter case and spaces at either end.
Decision 3: which details must be left alone?
| disabledFieldMappings | Fields left unchanged when an existing customer is updated. A disabled field is left out of the update, so WooCommerce keeps its value. Fields not listed are updated. |
|---|
The fields you can protect are email, first_name, last_name, billing (the whole
billing address, including billing email and phone), shipping (the whole shipping
address) and meta_data (the payment-term field).
- These apply to updates only. A new customer is always created with every field, because WooCommerce needs an email to create one.
- If every field is disabled, or only
meta_datais enabled and there's nothing to send, the update is skipped. - The customer's id and username can't be disabled: they're how the customer is found.
Only update the payment-term field
To change nothing but the payment-term field when a term changes, disable everything else:
"disabledFieldMappings": { "email": true, "first_name": true, "last_name": true, "billing": true, "shipping": true }
Fernbrook's spa accounts
Fernbrook's spas are set up in Unleashed, on either 30 Days or Prepaid terms. A plugin
on the store offers "pay on account" when the customer field account_ref holds a value.
Priya adds a Customer Update configuration and sets subscriptionMetadataKey to
account_ref, creditPaymentTerms to ["30 Days"] and upfrontPaymentTerms to
["Prepaid"]. Spas log in with their own email, which they sometimes change, so she
disables email. When a spa moves from Prepaid to 30 Days in Unleashed, their Unleashed
code is written to account_ref and pay on account appears at checkout.
Recap
- Customer Update writes customers into WooCommerce;
createEnabledandupdateEnabledboth default totrue. subscriptionMetadataKeyswitches on the payment-term field; empty means nothing is sent.- Credit terms write the identifier, up-front terms clear the field, other terms send nothing.
disabledFieldMappingsprotects details on updates only; new customers get every field.- The id and username can't be disabled.
Quick guides for this topic
Your progress is saved in this browser. Create a free account to keep it everywhere, take quizzes and earn certificates.