All updates

Turn a store purchase into an automated workflow

Store purchases now trigger your custom workflows, plus raw-query Snowflake sync, faster integration history, and bulk updates keyed to your own ID.

01 ·Turn a store purchase into an automated workflow

Your custom workflows can now react to a store purchase. When a trader redeems an item, the purchase starts every workflow you have set to watch for store purchases, so one redemption can run several of them at once. You add it like any other trigger and give it a name. There is nothing else to set up per workflow.

The trigger hands each workflow the details of what happened, so the steps you build can respond to the specific reward and the specific trader:

  • The item that was redeemed
  • The voucher or redemption option the trader chose
  • The trader, together with their profile information
  • Their coin balance before and after the purchase
  • When the purchase happened
Why it matters

When the work after a redemption runs on its own, your team stops hand-processing routine rewards, and the reward reaches the trader fast enough to keep the earn-and-spend loop worth their time. A reward that shows up late gives a trader one less reason to chase the next one.

Trigger event
Store Purchase
A trader buys from the store
Payload
Item boughtWhich traderCoins before / after
Your workflow runs
1
2
3
Illustration · A store purchase flows into your workflow steps

02 ·Write your own query for Snowflake sync

Teams that sync trader data from Snowflake get a new Use Raw Query toggle, available on the manual sync button and on every scheduled sync. With it off, the sync works as before: you map fields and add a filter, and the platform builds the query for you. With it on, you write the full query yourself, so you can use joins, derived columns, and logic the field-mapping setup cannot express. The preview that tells you how many records match still works, and scheduled syncs keep pulling results the same way.

Why it matters

Some Snowflake setups need joins or derived columns that the field-mapping form cannot express. Writing the query yourself means you pull exactly the records you want in one sync, with no second pass to clean up what the mapping could not reach.

03 ·Faster, steadier integration history

The history tables for Snowflake, HubSpot, and Salesforce syncs gained a set of new controls. Each table has a refresh button that reloads just that table without reloading the page, results are cached so moving between a category and its detail rows stays instant, new pages load in the background while the rows you are reading stay on screen, and the page keeps your scroll position as you move between the list and a category's details. All three integrations now share the same layout and behaviour.

04 ·Match on a custom field in the bulk-update step

When a workflow updates a group of traders at once, the bulk-update step now has an Identifier setting. Leave it on Email to match the usual way, or switch it to Identifier and a second dropdown appears listing your user custom fields; pick one and that step matches traders on that field when it runs. Each step keeps its own setting, and steps you built before this change stay on Email, so nothing shifts unless you change it.

Why it matters

If your records key traders by an internal account number, you can run bulk updates against that field and skip the step of translating everything back to email first. The update matches the way your own data already works, so fewer rows fall out as mismatches.

Also in this build
Fix

Duplicating a workflow now carries its field mapping across, so the copy behaves like the original with no mapping to rebuild.

29 May