Implementing Atomic in your organization

You understand how Atomic works, you have done some of our introductory tutorials (such as Introduction to the workbench, Authoring cards and Sending cards). Now you want to know how Atomic can be implemented in your organization.

A successful Atomic implementation typically has a few distinct phases, from orientation to BAU. This guide gives a high-level overview of key actions and deliverables of each phase.

Project phases

Phase 1: Orientation

The aim of this phase is to give your team a basic orientation of Atomic and a way to discover/learn about the key parts of the system and how they work. To do this we’ll use the Sandbox environment we’ve set up for you, as it doesn’t require any setup or installation to get started.

Some of the key actions in this phase are:

1. Log in and explore the Sandbox environment.
2. Send test data from the Workbench.
3. See cards display in our demo web app.

Phase 2: Example Integration (Proof of concept)

The demo web app is hosted by Atomic, but you’ll want to set up the SDKs in a development environment that you host and control. Your team will integrate the SDKs into a host application, and will experience how authentication works.

You can also explore the Atomic API by using a tool like Insomnia to send requests to Atomic. This will help familiarize you with the payload data that Atomic requires. You can also configure a webhook in the Workbench. This will be where Atomic sends response data when cards are actioned. You could use a tool such as Zapier as the webhook URL if you don’t want to set up an endpoint locally.

There is a Sandbox Environment already set up in your workbench, which can be used as a sandbox for developers (e.g. setting up the webhook). Or you could add another environment to your account.

Some of the key actions in this phase are:

1. Install the demo web app in a development environment.
2. Observe how SDK authentication works.
3. Configure your sandbox environment or create a developer-sandbox environment.
4. Send requests using an API development tool such as Insomnia.
5. Configure a webhook and receive responses via that webhook.

Phase 3: Pre-Integration Decisions

This is the point where you need to start making decisions about exactly how you’ll integrate Atomic into your applications. There are technical, design and product decisions to be made, and the right solution is different for every organization.

This process may require multiple iterations of your requirements. Testing or experimentation during this step will likely take place in your Sandbox environment.

Some of the key actions in this phase are:

1. Make a decision about UX considerations for each SDK. Check that they are compatible with your existing app architecture, design system and UX patterns.
2. Come up with some initial use cases for cards, even if only test use cases. These will be useful as you begin integration and proper Workbench testing.
3. Decide on a pipeline architecture for preparing and transforming data to send to Atomic and to receive from Atomic.

Phase 4: Integration

In this phase, you are underway with your actual integration. You will integrate Atomic’s SDKs into your applications and formally authenticate them. Workbench members will use the Workbench to author card templates for the initial use cases. Your initial data connections and pipelines will be built. Testing will begin. The work in this step will likely be done on your Sandbox or new environment.

Some of the key actions in this phase are:

1. Integrate Atomic’s SDKs into your applications.
2. Implement an authentication system to service the SDKs.
3. Author card templates for the initial use cases in the Workbench, including whether the card contains a notification, variables, embargo date, expiry time, or media.
4. Build initial data connections and pipelines.
5. Customize your theme to match your existing design system.
6. Test pipelines, cards, and integrations.

Phase 5: BAU / Ongoing

Once the integration is complete, you will be ready to start sending live cards to real customers. This will also necessitate building some structure around using Atomic into your existing workflows. There will likely be ongoing new data connections and use cases to create.

Some of the key actions in this phase are:

1. Decide on a lifecycle management approach for BAU cards (including testing practices).
2. Decide how to resource ongoing technical work, e.g. new data connections.
3. Learn how to use the Workbench to monitor and improve cards.
4. Subscribe to our changelog to receive emails whenever we make updates to the Atomic area(s) that most interest you.