> For the complete documentation index, see [llms.txt](https://docs.thewalletcrew.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.thewalletcrew.io/guides-animation/engage-and-animate/automatisation.md). # Automation Build an automation in the back office: choose when it runs, which passes it concerns, what it changes on each pass, and when it stops. An automation is a rule that updates wallet passes on its own. Once it is switched on, it picks the right passes at the right moment and changes them: a new look for a campaign, a reward, a message on the lock screen. It saves the team from updating thousands of passes by hand, and it makes sure every end-user receives the change at the right time, even customers who install their pass weeks after the campaign started. This page walks through the automation editor block by block, then shows ready-made combinations for the most common needs.

Real-world examples

* A fashion brand gives every loyalty card a Black Friday look on launch morning, announces the sale with a notification, and restores the usual design when the campaign ends. * A beauty brand greets each customer with a welcome message a few minutes after the card lands in their wallet, and never sends it twice. * A retailer switches a customer's card to the Gold design the moment the customer reaches the Gold tier. * A gift card programme reminds holders the day before their card expires, at 9 a.m. in their own time zone. * A brand moves every card from an old design to a new one, silently, without reissuing a single pass.

## How an automation is built Every automation answers the same five questions, always in the same order. The editor shows them as five stacked blocks, so reading an automation from top to bottom is enough to know what it does. | Block | Question | What it holds | | ------------ | ----------------- | -------------------------------------------------------------------------------- | | **Start** | When does it run? | A date, a repeating schedule, a date carried on each pass, or a customer action. | | **Audience** | Which passes? | Filters on the pass design, its theme, its data, and whether it is installed. | | **Actions** | What changes? | A benefit, new data, a new design, a theme, a notification. | | **End** | Until when? | After a single run, on a fixed date, or when someone switches it off. | | **Settings** | How fast? | On/off switch, sending pace, and data refresh. | Three ideas help when building one: * **One trigger per automation.** Two different moments, such as "on install" and "on the birthday", need two automations. * **All actions land together.** Every action is applied to the pass first, then the pass is sent to the phone once. The customer never sees a half-updated card. * **A refresh is silent; a notification is not.** Changing the data, design or theme updates the card quietly. Only the **Send a notification** action makes the phone show a message. ### Find the automations Automations live in the back office under **Engagement → Automations**. The list shows each automation with its actions, its schedule in plain words and its status.

Automations list in the back office, with Active, Inactive, Expired and All tabs and the Add new button — The tabs at the top filter automations by state, and the Status column shows whether each one is waiting for an event, watching for new passes, expired or disabled.

### The editor Clicking a row, or **Add new**, opens the editor. The left column shows the automation block by block; clicking a block opens its settings in the right-hand panel. The **Active** switch and the **Save** button sit at the top right.

Automation editor with the summary sentence at the top, the blocks in the left column and the Start settings on the right — The left column reads Start, Audience, actions, End and Settings from top to bottom; the right-hand panel shows the settings of the selected block.

Under the name, a summary sentence rewrites the whole automation in plain English and updates as the automation is built. It is the best check before saving: if the sentence does not describe the intended behaviour, the automation needs to be adjusted. ## Start: when it runs The Start block decides the moment the automation goes into action. It has three tabs: **Schedule** for anything tied to the clock, **Event** for something that happens to a pass, and **External input**, which is planned but not available yet. ### Schedule The Schedule tab offers four options, from the simplest one-off to a reminder calculated pass by pass. * **As soon as it is saved** runs once, about a minute after saving. It suits tests and urgent one-off changes, and concerns the passes that match at that moment. * **At a specific date** runs once, at the chosen date and time, in the time zone of the browser (shown under the field). A second choice then decides who receives it. **Once, on the run date** works like a photograph: only the passes that match on that day are concerned. **Then keep watching** turns the date into a start date: passes that start matching later are also served, once each. See [Keep watching](#keep-watching). * **On a repeating schedule** runs every hour, day or week at a chosen time. The audience is checked again at every run, so the same pass can be updated each time. This is ideal for keeping data up to date, and best kept away from notifications. * **Relative to a date on the pass** runs pass by pass, a set time before or after a date stored on each pass, such as an expiry date or a birthday. The time can be pinned, for example "1 day before expiry, at 9:00".

Start panel with On a repeating schedule selected, set to every day at 9:00 — A repeating schedule: pick hour, day or week, then the time of the run.

Start panel with Relative to a date on the pass selected, showing the date field, direction, offset and Pin to specific time — A date-based trigger: choose the date field, Before or After, the offset and its unit, and optionally pin a specific time of day.

{% hint style="info" %} **Relative to a date on the pass** only lists dates that the pass template exposes as date fields. If a birthday or an expiry date does not appear in the list, The Wallet Crew can add it to the template. {% endhint %} ### Event The Event tab makes the automation react to something that happens to a pass. It runs pass by pass, each time the event happens to a pass that belongs to the audience. | Event | Happens when | Options | | ---------------------------------------- | ------------------------------------------------------------ | -------------------------------------------------------------------------------------------------- | | **Pass added** | The customer adds the pass to Apple Wallet or Google Wallet. | **On the first add only** ignores re-installs and second phones; **On every add** counts each one. | | **A benefit is used** | A benefit is redeemed, for example at the till. | Which benefit templates count. | | **A benefit is credited** | Value is added to a benefit: a stamp, a top-up, a refund. | Which benefit templates count. | | **A benefit's balance moves either way** | A benefit is used or credited. | Rarely needed; one of the two options above is usually clearer. |

Event tab with Pass added selected and the On the first add only condition — Pass added: the Condition switch chooses between the first install only and every install.

Event tab with A benefit is used selected, the benefit template picker and the Add a delay after the event option — A benefit is used: pick one or more benefit templates, or leave the field empty to watch all of them. The delay option sits at the bottom.

Every event can be followed by a delay, for example "3 hours after the benefit is used", so the message does not arrive while the customer is still at the till. Benefit events run at most once per pass. ## Audience: who receives it The audience defines which passes the automation concerns. It is a list of conditions, and a pass must match all of them. To accept several values for the same field, such as "Gold or Platinum", the **In** operator takes a list.

Audience panel with three conditions and the estimated audience count — An audience with three conditions: installed passes, a customer identifier and a tier. The estimated count at the bottom shows how many passes match today.

### Start from installed passes Every new automation starts with the condition **Pass added · Any device**, which means "the pass is currently in a wallet". It is worth keeping: there is little point updating cards nobody has installed. It can be narrowed to **Apple** or **Google** only. ### Add conditions **Add a condition** offers five kinds of filter. | Condition | What it looks at | Example | | --------------- | ------------------------------------------------------------------------------------------ | -------------------------------- | | **Template** | The pass design the card is built from. | Template equals the loyalty card | | **Theme** | The theme currently applied to the card. | Theme equals "Summer sale" | | **Metadata** | Values the pass makes searchable: tier, points, store, country, VIP status, dates. | Metadata `tier` equals `gold` | | **Identifiers** | The customer's references in other systems, such as a CRM number or a loyalty card number. | Identifier equals `12345` | | **Pass added** | Whether, and on which wallet, the pass is installed. | Pass added on Apple |

Condition type list with Template, Theme, Metadata, Identifiers and Pass added — The five kinds of condition available under Add a condition.

Each condition then needs an operator: **Equals**, **Not equals**, **In**, **Not in**, **Contains**, **Starts with**, **Ends with**, and for data fields **Is empty** or **Is not empty**. Numbers and dates can also be compared with greater than or less than.

Operator list showing Equals, Not equals, In, Not in, Contains, Starts with and Ends with — The operators for a condition. In and Not in accept several values.

{% hint style="warning" %} **Prefer Equals for exact values.** Metadata and identifier conditions start on **Contains**. "gold" is contained in "rose-gold", so switch to **Equals** whenever an exact value is meant. {% endhint %} ### Estimated audience Under the conditions, the editor shows how many passes match today. The figure is calculated again when the automation actually runs. A count of zero is not an error: with **Keep watching**, an automation can start empty and serve passes as they become eligible. After changing a filter, **Refresh audience** in the menu at the end of the row in the automations list recalculates the figure, to see how many passes the automation will actually reach. ## Actions: what changes on each pass Actions are added with **Add an action**. Each type can be used once per automation, and they always run in the same order, whatever the order they were added in. The pass is then sent to the phone once. Because the notification comes last, it only goes out when the card already shows the new benefit, data, design and theme.

Add an action window listing Grant a benefit, Update the pass data, Change the pass template, Apply a theme and Send a notification — The five action types, in the order they are applied. An action already in the automation disappears from the list.

### Grant a benefit This action gives each pass of the audience a benefit, such as a discount, a free product or a reward, created from a **benefit template**. The validity and the stock come from the benefit template itself, not from the automation.

Grant a benefit panel with the benefit template search field and list — Pick the benefit template in the searchable list; each line shows its type and how long it stays valid.

### Update the pass data This action writes new values onto the pass, as pairs of a key and a value: a tier, an offer code, a flag. It is only useful with keys the pass design already reads; a new key stays invisible until the template displays it.

Update the pass data panel with a key, a value and the Add additional data button — One row per key and value. Add additional data adds a row and the bin icon removes it.

### Change the pass template This action moves the pass to another design, with its own layout, fields and images. The customer's data, identifiers and installation are kept, so the card simply changes in the wallet.

Change the pass template panel with the template picker and a reminder that nothing switches it back — Choose the new template in the list. The reminder underneath is important: the change is permanent.

{% hint style="warning" %} **The change is permanent.** Nothing switches the template back on its own. A seasonal design needs a second automation to restore the original. {% endhint %} ### Apply a theme A theme is a skin on top of the design: colours, images, sometimes a title. The fields and the structure of the card stay the same. Applying a theme replaces any theme already on the card, and editing a theme later restyles every card that carries it. The switch **Remove the theme instead** sends the card back to its normal look, which is the clean-up step at the end of a campaign. [Wallet pass themes](https://docs.thewalletcrew.io/configure/advanced-configuration/wallet/wallet-pass-themes) explains how themes are created.

Apply a theme panel with the Remove the theme instead switch and the list of themes — Themes appear as cards with their image and colours; the selected one is outlined. The switch at the top turns the action into a clean-up.

### Send a notification This action shows a message on the customer's lock screen. The message has a **Default** text plus one text per language the pass supports, and each phone displays the version matching its language, falling back to Default. A counter recommends staying around 120 characters so the message fits on screen.

Send a notification panel with the DEFAULT, EN and FR language tabs, the message box and the length counter — The language tabs sit at the top right. Check that every language tab is filled in before saving.

When the notification is the only action, an extra switch decides whether the card's data is also refreshed at the same time. On Google Wallet, the alert can read "You have a new message", with the full text visible on the card. [How to send push notifications](broken://pages/20de169d6fe82f8f065c21841ff6b69dd77f6e23) covers notifications in more detail. ## End: when it stops The End block decides how long the automation stays in action. The options depend on the trigger. | Trigger | End options | | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------- | | As soon as saved, or specific date (once) | After its single run. Nothing to set. | | Specific date, keep watching | **I stop it by hand**, **A fixed date**, or **The benefit template ends** when the automation grants a benefit. | | Repeating schedule | **I stop it by hand** or **A fixed date**. | | Date on the pass, or event | Runs until someone switches it off. |

End panel with the Keep watching until list: I stop it by hand, A fixed date, The benefit template ends — The end options of a watching automation. The last option is only available when the automation grants a benefit.

An automation whose end has passed shows as **Expired** in the list. A one-off automation whose date is already past will not run, even if it is switched back on; duplicating it with a new date is the way to run it again. ## Settings The Settings block controls the state and pace of the automation. * **Active** is the on/off switch at the top right. An inactive automation does nothing and appears under the **Inactive** tab. * **Throughput** sets how many passes are updated per second, from 1 to 50 (12 by default), and estimates how long the whole audience will take. For very large audiences, a lower pace spreads the load; passes above the platform's limit are postponed, never dropped. * **Update metadata** recalculates the searchable values of the pass after the run. It should be on when an action changes data that another automation filters on, for example when one automation sets the tier and another reacts to tier = gold. * **Name and tags**: a name is required to save; tags help group automations, for example by campaign.

Settings panel with the Throughput slider and the Update metadata switch — The Throughput slider shows the estimated duration for the current audience; the Update metadata switch sits underneath.

## Keep watching **Keep watching** is the most useful option for campaigns, and the one that deserves the clearest explanation. With **Once**, the automation takes a photograph of the audience on the run date and serves only those passes. With **Keep watching**, it serves that first group, then keeps looking for passes that start matching, and serves each of them once. A pass can start matching in three ways: * **It is installed.** With the default **Pass added** condition, a card installed after the start date is picked up within seconds. * **Its data changes.** The CRM, an API call or another automation changes a tier or a segment, and the pass now matches. This requires the data change to refresh the metadata (see **Update metadata** in Settings). * **The audience is widened.** Editing the conditions serves every newly matching pass that was never served before. A pass is never served twice by the same watching automation, even if it stops and starts matching again, or is installed on a second phone. {% hint style="warning" %} **Widening the audience acts immediately.** On a watching automation, changing "Gold" to "Gold or Silver" hands the actions to every existing Silver card at once. {% endhint %} ## Common automations The combinations below cover the most frequent needs. Each one lists what to set in every block.

Seasonal look and announcement

A campaign design on every card, announced with a message, then removed at the end. * **Start**: at a specific date, the morning of the launch, with **Then keep watching** so cards installed during the campaign get the look too. * **Audience**: Pass added, optionally restricted to the loyalty template. * **Actions**: Apply a theme (the campaign theme) and Send a notification announcing the campaign. * **End**: a fixed date, the last day of the campaign. * **Clean-up**: a second automation on the end date, with the audience Theme equals the campaign theme and the action Apply a theme with **Remove the theme instead**. No notification is needed.

Welcome on first install

A greeting the moment the card lands in the wallet. * **Start**: Event → Pass added → **On the first add only**, with a delay of about 10 minutes so the message does not arrive during installation. * **Audience**: Template equals the loyalty template. * **Actions**: Send a notification with the welcome message, optionally with Update the pass data to record that the welcome was sent. * **End**: runs until switched off. Re-installs and second phones do not trigger it again.

Tier upgrade

A new look and a message as soon as a customer reaches a higher tier. * **Start**: at a specific date (today) with **Then keep watching**, no end date. * **Audience**: Pass added and Metadata `tier` equals `gold`. * **Actions**: Change the pass template to the Gold design (or Apply a theme "Gold") and Send a notification congratulating the customer. * **End**: stopped by hand. Each customer is congratulated once. * **Good to know**: whatever updates the tier, whether the CRM, the API or another automation, must refresh the metadata so the change is noticed.

Expiry or birthday reminder

A message a set time before or after a date carried by each card. * **Start**: Relative to a date on the pass → the expiry date → Before → 1 day, pinned at 9:00. * **Audience**: Pass added and Template equals the gift card template. * **Actions**: Send a notification reminding the customer. * **End**: runs until switched off; each card receives its own reminder on its own date.

Follow-up after a reward is used

A thank-you after a coupon or a stamp reward is redeemed. * **Start**: Event → A benefit is used → the benefit template concerned, with a delay of 3 hours. * **Audience**: Pass added. * **Actions**: Send a notification thanking the customer for the visit. * **End**: runs at most once per pass.

One-off message to a segment

A single announcement to a group of customers, such as VIPs of one store. * **Start**: at a specific date, **Once, on the run date**. * **Audience**: Pass added, Metadata `isVip` equals true and Metadata `storeId` equals the store concerned. * **Actions**: Send a notification, with a version for each language. * **End**: after its single run.

Move cards to a new design

A silent migration of every card from an old design to a new one. * **Start**: at a specific date with **Then keep watching**, so cards still created from the old design are moved too. * **Audience**: Template equals the old template. Leave out **Pass added** if uninstalled cards should move as well. * **Actions**: Change the pass template to the new one, without notification. * **Settings**: lower the throughput for very large audiences, and switch on **Update metadata** if the new design calculates different values.

Regular data refresh

A value on the card kept up to date, quietly. * **Start**: on a repeating schedule, every day at 6:00. * **Audience**: Pass added and the template concerned. * **Actions**: Update the pass data, without notification, since a repeating automation would otherwise message the same customers every day. * **Good to know**: Google Wallet accepts about three updates per pass per day, so a more frequent schedule will not reach Android phones more often.

## Before switching it on A quick review before saving avoids most surprises: * The summary sentence at the top describes exactly the intended behaviour. * The estimated audience is in the expected range, or zero on purpose for a watching automation. * Conditions use **Equals** wherever an exact value is meant. * Every language tab of the notification is filled in. * **Update metadata** is on if an action changes data another automation relies on. * There is a plan to undo the change: theme removal, template switch back, or end date. * The automation was first tried on a few test cards, by filtering on an identifier, with both an iPhone and an Android phone. ## Check that it worked The most reliable check is the card the automation was meant to change. In **Wallet → Passes**, opening a pass shows its current state and everything that happened to it.

Pass overview with the template, the theme, the Apple Wallet and Google Wallet install dates and the identifiers — The Overview tab: check the current template and theme, and when the pass was added to Apple Wallet and Google Wallet.

The **Notifications** tab lists every message sent to the pass, per wallet, with its text. If a message is listed there but the customer did not see it, the cause is on the phone side, such as notifications being turned off for the pass. The **History** tab lists every event on the pass: created, installed, updated, theme changed, notification sent. Both tabs can take up to five minutes to show a new event.

Pass Notifications tab with a timeline of sent notifications per device — The Notifications tab: each message sent, with the wallet it went to and its text.

Pass History tab with counters per event type and a timeline of events — The History tab: the counters at the top summarise each type of event, and the timeline shows when each one happened.

On the automation side, the list status shows whether each automation is waiting, watching, reacting to events, expired or disabled. ### View the history of an automation Each automation keeps a record of its runs. It is the quickest way to confirm that an automation actually ran, when it ran, and whether it went well, without opening passes one by one. In the automations list, the **⋯** menu at the end of a row offers **View history**.

Row menu of an automation with Edit, View history, Refresh audience and Delete — The ⋯ menu at the end of each row in the automations list. View history opens the list of runs.

The **Execution history** page lists every run of the automation with its start date, its duration and its result in the **Success** column. A run that fails is tried again automatically, and the **Retry index** column shows which attempt is displayed. Runs are kept for the last 90 days.

Execution history page listing runs with their start date, duration, success status and retry index — Each line is one run. Check the start date and the Success column to confirm the automation ran as planned.

The **⋯** menu of a run opens **View detail**, a technical log of every step of that run. It is mostly useful when asking The Wallet Crew support to look into a specific run: sharing the execution ID shown at the top speeds up the investigation.

Execution detail page with the execution ID, start date, duration and the list of log entries — The detail of a run. The execution ID at the top is the reference to share with support.

## FAQ

Does every automation send a notification to customers?

No. Changing data, the design or the theme updates the card silently. Customers only receive a message when the automation includes the **Send a notification** action.

Can one automation react to two different moments?

No. Each automation has a single trigger. Two moments, such as the first install and the birthday, need two separate automations.

What is the difference between Once and Keep watching?

**Once** concerns only the passes that match on the run date. **Keep watching** serves those passes, then also every pass that starts matching later, for example a card installed during the campaign, each one only once.

How can I check that an automation actually ran?

Open the **⋯** menu of the automation in the list and choose **View history**. Each run appears with its start date, its duration and whether it succeeded. To check the result on a specific card, open the pass in **Wallet → Passes** and look at its **History** and **Notifications** tabs.

Why does the estimated audience show zero?

No pass matches the conditions today. That can be intended with **Keep watching**, where passes are served as they become eligible. Otherwise, check that each condition uses the right operator and value, for example **Equals** rather than **Contains**.

How do I undo a campaign look at the end of a campaign?

Create a second automation on the end date, with the audience Theme equals the campaign theme and the action **Apply a theme** with **Remove the theme instead**. Cards go back to their normal look silently.

Why did an automation with a past date not run when I switched it back on?

A one-off automation only runs on its date. Once that date has passed, switching it on again does nothing. Duplicate it and set a new date instead.

How often can a pass be updated on Google Wallet?

Google Wallet accepts about three updates per pass per day. A schedule that updates more often will not reach Android phones more often, so plan refreshes around that limit.

--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.thewalletcrew.io/guides-animation/engage-and-animate/automatisation.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.