Automated notification rules

Rules let you say "when this field on the pass changes, send this message" - and then PocketPass sends it for you, every time. A store credit balance ticking up. A tier moving from Gold to Platinum. A renewal date shifting.

No CRM automation to build. No API call to write. Configure it once on the template and it applies to every pass issued from it.

When rules fire

A rule fires when the value of its trigger field on a pass changes. It doesn't matter what changed it:

• A CRM sync picked up a new value from a customer property.
• Someone edited the pass in the dashboard.
• Your own systems called PATCH /v1/passes/{id} over the API.

All three route through the same place, so all three trigger the same rule.

If the value is the same after the change as before, nothing fires. If the trigger field ends up empty, nothing fires either - there's no useful message to send about a blank value.

Setting one up

Open the template and choose the Notifications tab (beside Pass template and Issuance form).

1. Set your Notification header if it's blank. This is the brand title shown on every push from this template - your company name, usually. It applies to rule-driven pushes, manual pushes, and API pushes alike.
2. Choose Add rule. Give it a name for yourself - customers never see it.
3. Pick the trigger field. Only fields you've defined on the template appear here.
4. Write the message. This is what customers read. Reference the field by wrapping its id in braces: Your store credit is now ${store_credit}. The "Insert field" chips underneath drop the right token in at the cursor.
5. Save.

The preview line under each rule shows how the message will read when it fires, using a sample value so you can spot a broken placeholder immediately.

Placeholders

Anywhere in the message body, {fieldId} is replaced by that field's current value on the pass:

• Your store credit is now ${store_credit} becomes Your store credit is now $18.00.
• Hi {first_name}, you've reached {tier} status! becomes Hi Alex, you've reached Platinum status!.

You can reference any field on the template, not just the trigger field. So a rule that fires when store_credit changes can still say Hi {first_name}, your balance is now ${store_credit} and both values will be current.

An unknown field id or an empty value renders as nothing - the rest of the message is still sent.

The 30-second cooldown

If the same trigger field is updated three times in quick succession - a CRM webhook bursting, a script looping - only the first change fires the rule. The next two are suppressed for 30 seconds per rule per pass.

This is deliberate. A pass that pings the lock screen five times in a minute gets deleted. Cooldowns keep an aggressive sync from becoming an aggressive push.

If you legitimately need to inform someone about several changes in a row, one push per change isn't the way to do it - send a single summary instead.

What rules can't do (yet)

• No conditions. A rule fires whenever the value changes, full stop. It doesn't fire only when the value crosses a threshold, matches a specific string, or increases rather than decreases. That's on the roadmap.
• No delay. A rule fires immediately (subject to the cooldown), not at a scheduled time. If you need "send tomorrow morning", use scheduling on a manual notification instead.
• No audience filter. Rules apply to every pass issued from the template. To message only a subset, use a manual notification with an audience.

Rules vs. sending a notification vs. CRM webhooks

Three ways to send a push. Pick the one that matches what you're doing.

Automated notification rule (this article) - PocketPass watches for a change and sends. Best when the same message should always follow the same change, on every pass, across every source of change.

Sending a notification - you compose and send from the dashboard. Best for one-off announcements, promotions, or anything targeting a filtered audience rather than every holder.

Trigger from your CRM - your CRM automation POSTs to PocketPass when its own conditions are met. Best when the trigger lives entirely in the CRM's own logic (a specific email opened, a specific list joined) and doesn't correspond to a value that lands on the pass.

Where the sent messages appear

Exactly the same places manual notifications do:

• On the customer's lock screen.
• On the back of their pass, so they can look back at it.
• In the pass's message log on its detail page in Passes.

The customer can't tell a rule-fired push from a manual one, and they don't need to. It's the same push.

Testing a rule before it goes live

Two options:

Toggle enabled off, save, edit values on a test pass, turn it on, edit again. The first save with enabled off proves the wiring; the second save with enabled on confirms the message you expect actually lands.

Set up the rule on a duplicated template used only for testing. Issue yourself a pass from it, PATCH the field via the API or edit it in the dashboard, and confirm the push arrives. Once you're happy, copy the rule across to the real template.

Where to go next

• Sending a notification - the manual counterpart.
• Trigger notifications from your CRM - when your CRM's own logic is what should decide.
• Live pass updates - what happens to the pass itself when a field changes.
• Fields and regions - the fields you can bind rules to.