Contact Created Trigger

Last updated: April 12, 2026

Last Updated: April 12, 2026

Customer-Facing Guide

What this trigger does

Contact Created Trigger starts the workflow when a brand-new contact is created and sent into Sendblue. It is most useful for first-touch automations, onboarding sequences, and any workflow that should only run the first time a person enters your Sendblue contact universe.

When this trigger is a good fit

  • You want a brand-new lead to enter a welcome, nurture, or handoff workflow immediately after creation.

  • Your downstream steps depend on the contact being new rather than merely updated.

  • You are building automations off imports, API/Zapier pushes, or CRM-driven create events and want one clean entry point.

What counts as “created” in practice

  • The workflow should fire when the contact is created as a new record, not when an existing record is edited later.

  • If another system is de-duping or merging contacts before they reach Sendblue, the workflow may behave differently than a manual “new lead” test.

  • If you are expecting this to run for returning contacts, updated phone numbers, or re-imported records, confirm whether those contacts are actually being created again or only updated.

What to check before turning it on

  • Make sure the fields your workflow needs (name, phone, tags, owner, custom variables, or source labels) are already present or will be added before the next step runs.

  • If your next action depends on assignment, tags, or CRM sync finishing first, add a short delay rather than assuming everything arrives instantly.

  • Confirm you do not also have a second trigger enrolling the same new contact into a competing or duplicate workflow.

Common workflow patterns

  • Create contact → short delay → assign owner → send first message.

  • Create contact → add tag → branch by source or campaign.

  • Create contact → wait for CRM data/custom variables → personalize the next message.

Common mistakes

  • Expecting the trigger to fire for updated contacts, not just newly created ones.

  • Sending immediately when the owner, tag, or custom variables have not finished syncing yet.

  • Using multiple entry paths that cause the same contact to receive overlapping automation.

  • Testing with a contact that already exists and assuming the trigger is broken when it does not re-enroll.

How to test and verify it

  1. Create a truly new test contact from the same source you expect in production.

  2. Open enrollment history / execution logs and confirm the contact enrolled at the right time.

  3. Check whether downstream steps saw the expected data, including assignment, tags, and custom variables.

  4. If the workflow enrolled but the next action behaved oddly, troubleshoot the downstream step rather than the trigger itself.

If the workflow still behaves unexpectedly

The fastest way to narrow it down is to separate trigger issues from timing issues. If the contact never enrolled, focus on whether a new contact was actually created. If the contact enrolled but later steps were wrong, review delay length, assignment timing, tag timing, and execution logs.

Related guides