Subscription businesses often have a surprisingly basic CRM problem.

Shopify knows whether someone has an active subscription. Your subscription app knows when their contract renews, pauses or cancels. But Klaviyo may only know that the customer once placed an order.

That creates problems as soon as you want to do something more sophisticated than send the same campaign to everybody.

You might want to:

• exclude active subscribers from a subscription acquisition promotion;

• send reactivation messaging to former subscribers;

• build different post-purchase journeys for subscribers and one-off buyers;

• remind customers about upcoming subscription billing;

• personalise campaigns based on subscription product or frequency;

• analyse how subscribers behave differently from non-subscribers.

To do that reliably, subscription status needs to become part of the Klaviyo customer profile.

A practical way to achieve this is:

Shopify subscription contract → Shopify Flow → Klaviyo event + customer properties

This article explains the data model and the logic behind the setup.

---

The basic architecture

The important principle is simple:

Shopify should remain the source of truth.

Klaviyo should not independently decide whether someone is subscribed.

Instead, whenever the subscription state changes in Shopify, that information should be passed into Klaviyo.

The system looks like this:

Subscription created or updated in Shopify

↓

Shopify Flow detects the change

↓

Flow sends an event to Klaviyo

↓

Klaviyo updates persistent customer properties

↓

Segments and lifecycle flows can use the new subscription state

This gives Klaviyo an up-to-date customer-level view without trying to recreate the subscription system inside the ESP.

---

The Klaviyo fields to create

For most subscription businesses, I would start with a small number of clear profile properties.

The objective is not to copy the entire subscription contract into Klaviyo.

You only need the information CRM will actually use.

Klaviyo property	Type	What it means
has_active_subscription	Boolean	Is this person actively subscribed right now?
has_ever_subscribed	Boolean	Has this person ever held a subscription?
subscription_status	String	The current subscription state, for example active, paused or cancelled.
subscription_contract_id	String	The Shopify subscription contract identifier.
subscription_product_name	String	The product associated with the subscription.
subscription_next_billing_date	Date/time	The next expected billing date.
subscription_updated_at	Date/time	When the subscription contract was last updated.
subscription_frequency	String	The customer's subscription interval or frequency.

The most important fields are the first two.

---

has_active_subscription

This answers:

Is this customer subscribed now?

Examples:

Active subscriber

has_active_subscription = true

Paused subscriber

has_active_subscription = false

Cancelled subscriber

has_active_subscription = false

Never subscribed

has_active_subscription = false

This property is particularly useful for campaign eligibility.

For example, imagine you are sending:

Subscribe today and get 20% off your first subscription.

You probably don't want existing active subscribers receiving it.

Your exclusion becomes very simple:

Exclude anyone where:

has_active_subscription = true

That single Boolean can become one of the most useful CRM properties in a subscription business.

---

has_ever_subscribed

This answers a different question:

Has this customer ever been a subscriber?

Once this becomes true, it should normally remain true.

If someone cancels, you do not reset their subscription history.

So:

Never subscribed

has_active_subscription = false

has_ever_subscribed = false

Current subscriber

has_active_subscription = true

has_ever_subscribed = true

Former subscriber

has_active_subscription = false

has_ever_subscribed = true

Those two Boolean fields together create a very useful customer-state model.

Active	Ever subscribed	Meaning
False	False	Never subscribed
True	True	Current active subscriber
False	True	Previous / inactive subscriber
True	False	Invalid state that should be investigated

That last combination matters.

If Klaviyo says:

has_active_subscription = true

but:

has_ever_subscribed = false

something has gone wrong in the data.

An active subscriber must logically also have subscribed at some point.

This gives you a built-in QA rule.

---

Why keep subscription_status as well?

You might reasonably ask why you need a status property if you already have the Boolean.

Because:

has_active_subscription

is useful for decision-making.

While:

subscription_status

is useful for understanding what happened.

For example:

Customer A

has_active_subscription = false

subscription_status = paused

Customer B

has_active_subscription = false

subscription_status = cancelled

They should both be excluded from an “active subscriber” segment.

But they may deserve completely different lifecycle messaging.

A paused customer may need:

Ready to restart?

A cancelled customer may need:

Here's what's changed since you left.

The Boolean controls eligibility.

The status adds context.

---

The Shopify Flows you need

I normally separate this into at least two workflows.

1. Subscription Created

Trigger:

Subscription contract created

Then check:

Subscription contract status = ACTIVE

If true:

Send an event to Klaviyo such as:

Subscription Created

and update:

has_active_subscription = true

has_ever_subscribed = true

subscription_status = active

plus the relevant contract details.

Why a separate creation workflow?

Because a newly created subscription may not immediately generate a later “subscription updated” event.

If you rely only on contract updates, a brand-new subscriber can potentially remain incorrectly marked in Klaviyo until something else changes.

2. Subscription Status Updated

Trigger:

Subscription contract updated

The workflow then checks the new state.

ACTIVE

Set:

has_active_subscription = true

has_ever_subscribed = true

subscription_status = active

PAUSED

Set:

has_active_subscription = false

has_ever_subscribed = true

subscription_status = paused

CANCELLED

Set:

has_active_subscription = false

has_ever_subscribed = true

subscription_status = cancelled

You can also send a Klaviyo event such as:

Subscription Status Updated

This gives you a clean profile state plus an event that can trigger lifecycle communication.

---

What about existing subscribers?

This is where implementations often break.

Live automation only fixes the future.

If you already have thousands of subscribers, they will not magically receive these new properties just because you switched the Shopify Flows on.

You need a historical backfill.

That usually means:

1. Retrieve existing subscription contracts.

2. Loop through them.

3. Identify the matching Klaviyo profile.

4. Write the current subscription properties.

5. Record the update as a backfill rather than pretending it was a new subscription.

I strongly prefer giving the backfill event its own name.

For example:

Subscription Backfill

rather than:

Subscription Created

Otherwise you risk historical customers accidentally triggering new-subscriber messaging.

---

A warning about multiple subscription contracts

There is one important architectural consideration.

Shopify Flow may trigger at subscription-contract level.

Your Klaviyo Boolean exists at customer level.

If a customer can hold multiple simultaneous subscription contracts, that matters.

Imagine:

Contract A = CANCELLED

Contract B = ACTIVE

A cancellation event for Contract A should not cause:

has_active_subscription = false

because Contract B is still active.

For businesses where multiple concurrent subscriptions are common, your workflow needs to check whether the customer has at least one remaining active contract before changing the customer-level Boolean.

That is exactly the kind of edge case worth thinking about before putting the automation live.

---

QA before turning it on

Do not activate the workflow and assume the data is correct.

Test at least:

New subscription

Expected:

true / true / active

Pause

Expected:

false / true / paused

Resume

Expected:

true / true / active

Cancellation

Expected:

false / true / cancelled

Former subscriber subscribing again

Expected:

true / true / active

Then confirm:

• the correct Klaviyo profile was updated;

• the event arrived;

• the properties exist on the profile;

• Boolean values are actually Booleans;

• dates are valid;

• the right segments update;

• historical customers do not accidentally enter new-customer flows.

The workflow is only finished when the customer state in Klaviyo matches the customer state in Shopify.

---

Want the Shopify Flows instead of building them manually?

I've packaged the underlying setup into the:

Brutish Shopify Subscription → Klaviyo Automation Pack

It includes:

• Subscription Created Shopify Flow;

• Subscription Status Updated Shopify Flow;

• Historical Subscription Backfill Flow;

• Klaviyo property schema;

• event structure;

• setup instructions;

• QA checklist;

• troubleshooting notes.

You can import the workflows into Shopify Flow, configure them for your own environment and use the accompanying documentation to verify the integration.

[Join the wishlist for the Shopify Subscription → Klaviyo Automation Pack]

 

---

Want to build the CRM programme around the data?

Getting subscription status into Klaviyo is only the infrastructure.

The next question is what you actually do with it.

The Brutish Subscription CRM Guide goes deeper into:

• subscriber segmentation;

• acquisition vs reactivation;

• subscriber onboarding;

• paused customer journeys;

• cancellation;

• renewal;

• winback;

• campaign exclusions;

• subscription-specific content;

• measurement.

[Join the waitlist for the Subscription Segmentation & Lifecycle Guide]

---

Need a custom setup?

Every subscription model is slightly different.

If your Shopify setup involves custom subscription logic, multiple contracts, additional subscription apps, bespoke customer states or more complex Klaviyo lifecycle requirements, Brutish can design and implement the integration for you.

Shopify → Klaviyo integrations, CRM architecture and lifecycle automation.

[Work with Brutish]