Shopify Customer Erasure Deadline Compliance Gate with Kestra

id: shopify-customer-erasure-deadline-compliance-gate
namespace: company.team

description: |
  Check whether a Shopify customer flagged for a GDPR/CCPA erasure request still exists, classify
  how close the request is to its legal deadline, auto-delete the record once past the deadline
  only when explicitly authorized, alert Slack otherwise, and log a governance audit trail either
  way.

inputs:
  - id: shopify_store_domain
    type: STRING
    displayName: Shopify store domain
    description: Store domain used for Admin API calls, for example my-store.myshopify.com.
    defaults: "my-store.myshopify.com"

  - id: customer_id
    type: STRING
    displayName: Customer ID
    description: Shopify customer ID flagged for an erasure (right to be forgotten) request.
    defaults: "0000000000"

  - id: erasure_requested_at
    type: STRING
    displayName: Erasure requested at
    description: ISO-8601 date the erasure request was received, for example 2026-09-01.
    defaults: "2026-09-01"

  - id: erasure_deadline_days
    type: INT
    displayName: Erasure deadline in days
    description: Legal deadline in days from erasure_requested_at by which the
      customer record must be deleted.
    defaults: 30

  - id: confirm_delete
    type: BOOL
    displayName: Confirm automatic deletion
    description: When true, this flow is authorized to delete the customer itself
      once the deadline has passed. When false, a passed deadline only alerts
      Slack so a human deletes it.
    defaults: false

tasks:
  - id: check_customer
    type: io.kestra.plugin.shopify.customers.Get
    description: Read-only probe. Shopify's own API throws when the customer ID is
      not found, which this treats as proof the erasure already happened;
      allowFailure converts that throw into a missing output instead of failing
      the flow.
    allowFailure: true
    storeDomain: "{{ inputs.shopify_store_domain }}"
    accessToken: "{{ secret('SHOPIFY_ACCESS_TOKEN') }}"
    customerId: "{{ inputs.customer_id }}"

  - id: evaluate
    type: io.kestra.plugin.core.output.OutputValues
    description: Classifies the request as already erased, still within the legal
      deadline, or overdue, folding confirm_delete into the overdue
      classification so the Switch branch needs no further nesting.
    values:
      days_since_request: >-
        {{ ((now() | timestamp) - ((inputs.erasure_requested_at ~ 'T00:00:00Z')
        | timestamp)) / 86400 | number }}
      severity: >-
        {{ outputs.check_customer is not defined ? 'ERASED' : ((((now() |
        timestamp) - ((inputs.erasure_requested_at ~ 'T00:00:00Z') | timestamp))
        / 86400) <= inputs.erasure_deadline_days ? 'WITHIN_DEADLINE' :
        (inputs.confirm_delete ? 'OVERDUE_AUTO_DELETE' : 'OVERDUE_NEEDS_HUMAN'))
        }}

  - id: route
    type: io.kestra.plugin.core.flow.Switch
    description: ERASED and WITHIN_DEADLINE just log. OVERDUE_AUTO_DELETE performs
      the safe remediation (the deletion is the already-requested, correct
      outcome). OVERDUE_NEEDS_HUMAN alerts Slack because this flow was not
      authorized to delete on its own.
    value: "{{ outputs.evaluate.values.severity }}"
    cases:
      "ERASED":
        - id: log_erased
          type: io.kestra.plugin.core.log.Log
          message: "Customer {{ inputs.customer_id }} no longer exists in Shopify; the
            erasure request is already fulfilled."
      "WITHIN_DEADLINE":
        - id: log_within_deadline
          type: io.kestra.plugin.core.log.Log
          message: "Customer {{ inputs.customer_id }} still exists, {{
            outputs.evaluate.values.days_since_request }} day(s) into a {{
            inputs.erasure_deadline_days }}-day erasure deadline."
      "OVERDUE_AUTO_DELETE":
        - id: delete_customer
          type: io.kestra.plugin.shopify.customers.Delete
          description: Performs the erasure now that the legal deadline has passed and
            confirm_delete explicitly authorizes this flow to act; Shopify's
            delete is idempotent.
          storeDomain: "{{ inputs.shopify_store_domain }}"
          accessToken: "{{ secret('SHOPIFY_ACCESS_TOKEN') }}"
          customerId: "{{ inputs.customer_id }}"
        - id: alert_auto_deleted
          type: io.kestra.plugin.slack.notifications.SlackIncomingWebhook
          url: "{{ secret('SLACK_WEBHOOK_URL') }}"
          payload: |
            {{ {'text': 'OVERDUE_AUTO_DELETE: customer ' ~ inputs.customer_id ~ ' was ' ~ outputs.evaluate.values.days_since_request ~ ' day(s) into a ' ~ inputs.erasure_deadline_days ~ '-day erasure deadline. This flow deleted the record automatically because confirm_delete is true.'} | toJson }}
      "OVERDUE_NEEDS_HUMAN":
        - id: alert_overdue
          type: io.kestra.plugin.slack.notifications.SlackIncomingWebhook
          url: "{{ secret('SLACK_WEBHOOK_URL') }}"
          payload: |
            {{ {'text': 'OVERDUE_NEEDS_HUMAN: customer ' ~ inputs.customer_id ~ ' is ' ~ outputs.evaluate.values.days_since_request ~ ' day(s) into a ' ~ inputs.erasure_deadline_days ~ '-day erasure deadline and still exists. Set confirm_delete to true to let this flow delete it, or delete it manually now.'} | toJson }}

  - id: summary
    type: io.kestra.plugin.core.log.Log
    message: "Shopify customer erasure deadline compliance gate complete for
      customer {{ inputs.customer_id }}: severity {{
      outputs.evaluate.values.severity }}."

errors:
  - id: alert_flow_failure
    type: io.kestra.plugin.slack.notifications.SlackIncomingWebhook
    url: "{{ secret('SLACK_WEBHOOK_URL') }}"
    payload: |
      {{ {'text': 'Shopify customer erasure deadline compliance gate failed (execution ' ~ execution.id ~ '). Check the logs.'} | toJson }}

triggers:
  - id: daily
    type: io.kestra.plugin.core.trigger.Schedule
    description: Shipped disabled. Enable once SHOPIFY_ACCESS_TOKEN and
      SLACK_WEBHOOK_URL are set and the inputs point at a real erasure request;
      confirm_delete stays false by default so a passed deadline alerts a human
      rather than auto-deleting until you deliberately opt in.
    cron: "0 9 * * *"
    disabled: true
    inputs:
      shopify_store_domain: "my-store.myshopify.com"
      customer_id: "0000000000"
      erasure_requested_at: "2026-09-01"
      erasure_deadline_days: 30
      confirm_delete: false

GDPR and CCPA give a customer the right to have their data erased, and give the business a hard deadline to actually do it. Shopify's Admin API can delete a customer, but it tracks nothing about why or by when, so an erasure request that gets flagged and then forgotten quietly turns into a compliance violation with no alarm attached. This blueprint checks whether the flagged customer record still exists, measures the request's age against the deadline you set, and only deletes it automatically once you have explicitly said this flow is allowed to.

This blueprint was created by Mohit Jeswani.

How it works

check_customer (io.kestra.plugin.shopify.customers.Get) reads the customer by ID. Shopify's own API throws when the ID is not found; allowFailure: true turns that throw into a missing output instead of failing the flow, which this blueprint treats as proof the erasure already happened.
evaluate (io.kestra.plugin.core.output.OutputValues) computes how many days have passed since erasure_requested_at and classifies the request as ERASED, WITHIN_DEADLINE, OVERDUE_AUTO_DELETE, or OVERDUE_NEEDS_HUMAN, folding confirm_delete into the overdue classification itself.
route (io.kestra.plugin.core.flow.Switch):
- ERASED / WITHIN_DEADLINE: logs the current state, no action needed.
- OVERDUE_AUTO_DELETE: runs io.kestra.plugin.shopify.customers.Delete (the safe remediation, since deletion is the already-requested, correct outcome) and posts a Slack notice that it happened automatically.
- OVERDUE_NEEDS_HUMAN: posts a Slack alert instead of deleting, because this flow was not authorized to act on its own.
summary logs the severity, closing the governance cycle.
errors alerts Slack if the flow itself fails, for example an expired access token.

What you get

A deadline measured from the real request date you supply, not a guess based on when someone happens to notice the record is still there.
A remediation that only ever deletes a record that was already supposed to be deleted, and only when you have explicitly set confirm_delete to allow it.
A Slack alert that tells a human exactly what to do (set confirm_delete, or delete it manually now) when the flow is not authorized to act.

Who it's for

Privacy, legal, and data-protection teams who own GDPR/CCPA erasure request fulfillment for a Shopify store and need the deadline enforced, not just logged in a spreadsheet.
Teams evaluating the Shopify plugin who want a worked example of customers.Get and customers.Delete used together as a compliance gate, distinct from this repo's existing Shopify blueprints, which track order and product-stock data rather than customer-record lifecycle.

Why orchestrate this with Kestra

Shopify can delete a customer on request, but it has no concept of a legal deadline, no escalation when one is missed, and no Slack integration of its own. Kestra keeps erasure_requested_at, erasure_deadline_days, and confirm_delete as flow inputs, turns a single customer lookup into a deadline decision, and keeps a full execution history proving exactly when each erasure request was checked and what happened.

Prerequisites

A Shopify store with a private or custom app Admin API access token that can read and delete customers.
At least one real customer ID to test against (a customer already deleted, and a customer still present, to confirm both branches).
A Slack incoming webhook URL.

Shopify is a hosted SaaS platform with no official standalone Docker image, so check_customer cannot be exercised against a local container; validate against a Shopify development store, which is free, before pointing this at a production store.

Secrets

SHOPIFY_ACCESS_TOKEN: the Shopify Admin API access token used by check_customer and delete_customer. In Kestra OSS, provide it as the base64-encoded environment variable SECRET_SHOPIFY_ACCESS_TOKEN.
SLACK_WEBHOOK_URL: used by both Slack alert branches and the errors block. In Kestra OSS, provide it as the base64-encoded environment variable SECRET_SLACK_WEBHOOK_URL.

Inputs

Input	Default	Purpose
`customer_id`	`0000000000`	Shopify customer ID flagged for erasure
`erasure_requested_at`	`2026-09-01`	Date the erasure request was received
`erasure_deadline_days`	`30`	Legal deadline in days from the request date
`confirm_delete`	`false`	Authorizes this flow to delete the customer itself once overdue

Outputs

{{ outputs.check_customer.customer }}: the customer record, when it still exists (id, email, createdAt, tags, note, and more).
{{ outputs.evaluate.values.days_since_request }} / .severity: how old the request is, and ERASED, WITHIN_DEADLINE, OVERDUE_AUTO_DELETE, or OVERDUE_NEEDS_HUMAN.

Pitfalls

customers.Get throws on a missing ID rather than returning an empty result; this is the mechanism this blueprint relies on to detect "already erased," so removing allowFailure: true would make every already-erased customer fail the whole execution instead of being classified ERASED. Verified directly against the task's own source, since its Javadoc example does not show this behavior explicitly.
erasure_requested_at is parsed as a plain date at midnight UTC; a request logged in a different timezone can be off by up to a day in days_since_request, which rarely matters against a 30-day deadline but is worth knowing for a tighter one.
confirm_delete is a single flag for the whole flow, not per-request; a scheduled run with confirm_delete: true will auto-delete every overdue customer it is pointed at, so scope one flow execution to one request (or one batch you have already reviewed) rather than a store-wide sweep.

Quick start

Add the SHOPIFY_ACCESS_TOKEN and SLACK_WEBHOOK_URL secrets.
Create a test customer in a Shopify development store and set customer_id to its ID, with erasure_requested_at far enough in the past to be overdue.
Run the flow with confirm_delete: false and confirm alert_overdue fires.
Run it again with confirm_delete: true and confirm delete_customer removes the test customer and alert_auto_deleted fires.
Run it a third time and confirm log_erased fires now that the customer is gone.
Enable the daily trigger per real erasure request once the inputs reflect it.

How to extend

Feed customer_id and erasure_requested_at from a privacy-request ticketing system instead of hardcoding one request per flow run.
Add a Loop over a list of tracked erasure request IDs to check a whole queue in one scheduled run, with confirm_delete left false until each one is reviewed.
Chain an export of the customer's orders via io.kestra.plugin.shopify.orders.List before delete_customer runs, to keep an anonymized record for accounting without retaining personal data.

Shopify Customer Erasure Deadline Compliance Gate

How it works

What you get

Who it's for

Why orchestrate this with Kestra

Prerequisites

Secrets

Inputs

Outputs

Pitfalls

Quick start

How to extend

Links

Tasks

Orchestrate with Kestra

Share this Blueprint

Create a Blueprint

New to Kestra?

Shopify Customer Erasure Deadline Compliance Gate

How it works

What you get

Who it's for

Why orchestrate this with Kestra

Prerequisites

Secrets

Inputs

Outputs

Pitfalls

Quick start

How to extend

Links

Tasks

Orchestrate with Kestra

Share this Blueprint

Create a Blueprint

More Business Blueprints

NocoDB Database Platform Health, Storage Engine, and Project Sentinel

MongoDB Unused Index and Memory Efficiency Auditor

Send a daily Odoo sales digest to Slack

MySQL Long-Running Transaction and Lock Contention Sentinel

MongoDB Slow Query and Collection Scan Profiler

Moodle Grading Backlog Sentinel

New to Kestra?