Event Streams gives you a live channel for moving data the moment it happens. Instead of waiting for a scheduled job to pick up new records, you publish each event as it occurs and let every interested subscriber react to it right away. This page explains what an event stream is, how it differs from a pipeline, and where to go next to set one up.
Overview
An event stream is a real-time, publish/subscribe message channel. A source publishes discrete events — a form submission, a status change, a sensor reading, a payment confirmation — onto a stream, and any number of subscribers can consume those events as soon as they arrive. There is no polling and no waiting for a batch window. Because the channel is decoupled, you can add or remove subscribers without touching whoever is publishing the events, and each subscriber processes the stream independently, at its own pace.
Every event on a stream follows a schema you define up front, so downstream consumers always know what fields to expect. Streams also keep a running log of messages, which means you can replay recent activity, inspect what was sent, and recover cleanly if a subscriber falls behind or a message needs to be reprocessed.
Event streams vs. pipelines
Pipelines and event streams both move data, but they solve different problems. A pipeline connects a source and a destination on a schedule, or continuously syncs data in bulk, and is built for moving large volumes of records between systems — for example, syncing a full customer table from a database into your workspace every hour. An event stream, by contrast, is built for individual, time-sensitive occurrences that multiple parts of your system need to know about the instant they happen.
Use a pipeline when you need to replicate or transform data between a source and a destination on a recurring or continuous basis. Use an event stream when you need to broadcast discrete happenings — such as a record being created, updated, or crossing a threshold — to one or more automations, apps, or services in real time. It is common to use both together: a pipeline keeps your data current in bulk, while event streams notify the rest of your system whenever something specific worth acting on occurs.
How the Event Streams area is organized
Once you understand the concept, the Event Streams section is organized around the full lifecycle of a stream, from creating it to monitoring what flows through it. Each area has its own page with more detail:
Event Streams Manager — the list of every stream you have access to. From here you create a new stream, edit or share an existing one, and delete streams you no longer need.
Event Stream Schema — where you define the fields and data types that make up each event, including which fields act as primary keys, and what you can still change once a stream is live.
Event Stream Logs & Usage — a browser for the messages passing through a stream, along with subscriber activity, lag, and the status of any messages that failed to deliver.
Event Stream Settings — configuration for how a stream behaves over time, including how failed messages are handled, how the stream is partitioned, how long data is retained, and how to reset a stream if needed.
Start with the Event Streams Manager to create your first stream, define its shape in the schema, and then use the logs and settings pages to keep it healthy as data flows through it.
Notes
An event stream is meant for discrete, time-sensitive events, not for bulk historical loads — use a pipeline for large one-time or recurring transfers instead.
Subscribers read from a stream independently, so a slow or failing subscriber does not block other subscribers from receiving events.
Events that a subscriber cannot process successfully can end up in a dead letter queue, which you can review and republish once the underlying issue is fixed.