How Atomic works
Atomic is a platform for surfacing the right message to the right customer at the right moment, and making sure something actually happens as a result. Instead of a notification that pulls customers out of your app to read a one-way message, Atomic delivers interactive, native UI directly inside your app. These are experiences customers can respond to, act on, and complete in the moment. And your content team builds and publishes them on their own, without pulling in engineering for every new message.
The three parts of the platform
Atomic has three main components, and understanding how they connect makes everything else easier.
Your back-end integrations connect Atomic to your existing customer systems. They feed Atomic the data it needs to know who your customers are and what they've done, this is data that Atomic can then use to personalise the messages they receive. Your development team sets up and maintains this layer.
The Atomic Workbench is where you build and manage everything; cards, Action Flows, customer segments, push notifications, and analytics. If you're a content designer, product owner, or CX lead, this is where you'll spend most of your time.
The Atomic SDKs are integrated into your mobile and web apps. Your development team integrates them once, and from that point on, Atomic can surface cards inside your app without needing app updates. The SDK is the bridge between the Workbench and your customer's screen.
For technical integration detail – SDK installation, APIs, and authentication – see the Atomic developer documentation.
Your development team sets up the SDK and containers once. After that, publishing cards and managing Action Flows happens entirely in the Workbench – no dev involvement required.
The building blocks
Once the SDK is in your app, four building blocks work together every time a customer sees a card.
An action card is the message your customer sees. Cards are interactive, they can include images or videos, body copy, input fields, buttons, and secondary screens (known as subviews). They're built in the Workbench and published as part of an Action Flow.
A stream is a collection of cards. You publish cards to a stream through the Workbench, and a container then displays those cards. A single stream can feed more than one container, so the same instance of a card feed can appear in several places across your app at once.
A stream container (often just called a container) is a UI component, provided by the Atomic SDK, that fetches cards from a stream and renders them inside your app. It's the display wrapper around the content. Where it sits in your app's layout and which display mode it uses (a scrollable feed, a single embedded card, a full-screen overlay, and so on) is a product decision; your development team integrates it there once. Each container displays exactly one stream. Because the container is identified by a key and configured in the Workbench, you can change which stream of cards it shows without a new app release. Containers handle their own empty states: when there are no active cards to show, a container can collapse entirely so your surrounding app content fills the space naturally.
An Action Flow is the orchestration layer that controls when a card is sent, to whom, and what happens after the customer responds. An Action Flow can be as simple as a single card sent to a segment of customers, or as complex as a multi-step journey that adapts based on customer behaviour. You configure Action Flows in the Workbench. Action Flows are the basis of everything you send to a customer, from a single card to a complex, multi-step sequence.
What this means in practice
When a card appears in your customer's app, here's what happened: an event or condition triggered an Action Flow in the Workbench, which sent a card to a stream, which appeared in a container your dev team placed in the UI – styled to match your brand through a theme your design or dev team configured.
Your job, as the person building and managing content in the Workbench, starts before any of that. It starts with deciding what you want your customer to do, and working backwards from there.
For more on that, see Start with the outcome.
Glossary
Action card – The interactive message your customer sees in the app. Can be informational, multi-step, or collect input.
Action Flow – The rules that control when a card is sent, to whom, and what happens after the customer responds. Configured in the Workbench.
Container – The UI component, provided by the Atomic SDK, that displays a stream inside your app. Displays exactly one stream; configured in the Workbench.
SDK – The lightweight code your development team installs in your mobile or web app. It's how Atomic gets cards onto your customers' screens.
Stream – A collection of cards. A stream can feed more than one container, and each container displays exactly one stream.
Theme – The visual style applied to cards – colours, fonts, button styles. Configured once by your design or development team.
Workbench – Atomic's back-office platform, where you build cards, configure Action Flows, manage segments, and publish content.
For technical integration details; SDK installation, authentication, and stream configuration – see Installing Atomic SDKs.