Understanding records

A record is one customer, order, product or other entry in your business model. Its schema defines the fields; the supplied values give an audience or email something concrete to use. This lesson covers adding, inspecting and updating those records.

Add a record

Open Records in the top navigation and pick the schema you want. From there:

• One at a time. Contact schemas have an "Add" button named after the schema (Add Customer), object schemas have a "New" one (New Product). You get a form built from that schema's fields.
• In bulk. Contact schemas have an Import button on the same row. Every schema also has an Import tab under Settings, then Schemas. Both take a CSV. See getting your data in.
• From your systems. Records also arrive through the API, from a form submission, from an integration, or from a workflow step. Whichever route they take, they go through the same checks.

Contacts and objects

Two of the three schema types produce records that behave the same way underneath. The difference is whether you can email the thing.

A contact carries extra fields an object does not need: consent, subscriptions, and email statistics. An object never receives an email, but knowing your products and orders is how you personalize the email you send to people. Events, the third type, work differently and have their own page.

How maxclicks keeps duplicates out

Import and upsert operations match within the selected schema. Contacts use a platform ID when supplied. Otherwise userId takes priority, email is used only without a user ID, and phone only without either. Objects use platform ID or externalId.

This is a priority rule, not a search for any field that happens to match. Sending a new user ID alongside an email can describe a different profile from an existing email-only contact. Without a usable identity, repeated input can create repeated records.

Keep your source identifier stable: use userId for people and externalId for objects. Select the intended API operation too: explicit create, update and upsert have different conflict outcomes. Contacts and Objects explain those distinctions.

Sending a field also updates it

Because a write is both a lookup and an update, referencing a record can change it. Sending a template to [email protected] with a first name of "Ada" attached does more than address the email: it finds that contact and writes "Ada" into their first name.

That is usually what you want, and it is the reason you never have to send a whole record to reference one. An email address on its own is enough to find or create a contact. It is also worth remembering when a system of yours holds stale values: whatever it sends, it also saves.

When an identifier is already taken

Sometimes a write hands a record an identifier that already belongs to a different record. Nothing is silently merged. Depending on the route, maxclicks either applies everything that does not clash and reports the one change it skipped, or refuses the write and changes nothing. Resolve the source mapping and inspect the affected profiles; maxclicks does not automatically merge their identity, history or consent for you.

Which route does which is worth knowing before you write a sync, and contacts spells it out.

Fields you cannot set

Some fields are maintained by maxclicks: creation/update timestamps, contact source and email statistics. Evaluated relationships and computed attributes are also read-only outputs, not values an import or record write can set. Ordinary public record responses do not include those expanded results.

Next

Understanding events: the records you fire instead of edit.