Core concepts
Understand connections, events, customers, journeys, goals, consent, and sending identities before building automation.
The signal-to-email flow
- 01
A connection authenticates the source
Each source has its own credential, status, event contract, and operational counters.
- 02
An event records something that happened
Track calls, identity updates, provider webhooks, hosted form submissions, and internal activity enter a common customer-event ledger.
- 03
Identity resolves the customer
Source-scoped user, anonymous, group, and alias IDs link activity to one customer record when sufficient identity is present.
- 04
A journey evaluates the signal
Trigger conditions, delays, goal exits, suppression state, and sender readiness determine the next eligible action.
- 05
A reviewed email is sent
The email uses grounded customer context and an approved sending identity. Sending never overrides consent or suppression.
Objects you will work with
| Object | Purpose | Practical rule |
|---|---|---|
| Connection | Authenticates and labels an event source | Use separate production and staging connections |
| Event | Immutable evidence that something happened | Use stable names and message IDs |
| Customer | Resolved person, identifiers, traits, and consent state | Prefer your durable application user ID |
| Journey | Trigger, conditions, actions, waits, and exits | Define the goal before activating |
| Goal | The outcome that stops or measures a journey | Choose a customer behavior, not an email metric |
| Sending identity | Verified From address and reply behavior | Complete domain authentication first |
Separate environments
Use distinct connections for local development, staging, and production. A connection is an operational and identity boundary, so this prevents test events from enrolling real customers and makes rotation safer.