Activity streaks, coin expiry, and a fuller audit log
Set up activity streaks, give coins a scheduled expiry, track member account events in the audit log, and run bulk updates through the API with status polling.
01 ·Set up activity streaks
A broker can now build activity streaks from community settings. Each streak has a name, a timezone, and a start date, and counts a chosen action as a completed period: a daily visit, a message sent, XP earned, or a numerical or text custom field. The timeframe can be a daily window or a rolling window of so many hours, conditions can be combined with AND or OR rules, and each streak can be edited or deleted from the settings panel.
A streak is the cleanest version of the daily return-visit habit: come back, keep the run going. Letting a broker define what counts and over what window means the streak can reward the behaviour their program actually cares about.
02 ·Give coins a scheduled expiry
Coins can now be set to expire on a schedule a broker controls. Expiry runs either on a repeating cycle or as a one-time date, set in the currency settings, and the expiry shows in the gamification log so a broker can see what is scheduled. A trader's coins now carry a clear shelf life.
Coins that never expire pile up as a standing liability and lose their pull. A shelf life keeps the earn-and-spend loop moving, giving traders a reason to redeem while their coins are live instead of leaving them parked.
03 ·The audit log now tracks member account events
The audit log gained a set of member-side account events. Entries come in three forms: an operational action such as a login or a one-time code sent, a field value added such as a phone number, and a field value changed showing the old and new side by side, as for a display name or email. The events span registration, sign-in, profile edits, privacy settings, notifications, and subscription changes.
04 ·Run bulk updates through the API
Bulk member updates can now be driven and tracked through the API. A bulk-update call returns a job ID, a status endpoint reports whether the job is queued, running, or done with counts and a duration, and a details endpoint returns the full paginated list of records that succeeded or failed. A broker's own systems can run a bulk update and follow it to completion without watching the admin screen.
A broker syncing loyalty data from their own stack needs to know a bulk job landed, not just that it was sent. A job ID with status and per-record results turns bulk update into something an integration can drive and reconcile on its own.
Message loading no longer fails on very large communities, where a call-stack limit could stop history from loading.
29 OctWebhook integrations now work on a newly created community from the start, rather than waiting on a missing setup record.
29 Oct