Workflows built over the API, and loyalty data in Databricks

A Workflow Builder API lets scripts and AI agents build and test Data Workflows, Databricks receives client data and logs, and Salesforce syncs Account fields.

01 ·Data Workflows, built and tested through the API

The Workflow Builder API does what the Data Workflows canvas does. With a community API key that holds the Workflow Builder permission, a script can list the step types, create a workflow with its trigger, add and edit steps and router branches, test it, deploy it and read its runs. AI agents get the same tools through an MCP endpoint on the same key, and a workflow built this way opens in the canvas like any other.

Each test runs in one of two modes. A live test runs the real steps and can pay rewards. A dry run follows the workflow with the trigger data supplied and reports what each step would do, such as the XP it would add or the request it would send, and writes and sends nothing. Every edit carries the revision it started from, and the API refuses an edit made against an older revision. Credentials stored in a step come back masked in every response.

02 ·Client data synced into Databricks

Databricks is a new integration. The broker's team connects a Databricks workspace through a service principal, maps platform fields, and the platform writes them to two tables: a current-state table with one row per client, and a history table. Each mapped field syncs every 2, 4, 6 or 12 hours. A scheduled run picks up the clients whose XP, coins, level, tier, roles or custom fields changed in that interval, and a manual full sync refreshes every eligible client, profile fields included.

When a value changes several times in one interval, the current-state table holds the latest value and the history table gets one row for that client and field, carrying the same latest value. A retried run adds no second history row.

03 ·Program logs delivered to Databricks as CSV files

The same integration's Log Export sends logs to a Databricks volume as CSV files, daily or weekly, one file per log: the Gamification Log, Milestone Log, API Log, Mini Games Log and Raffles Log. An admin can also export a chosen past date range. Each run covers its own period with no gap or overlap against the next, and its manifest, listing the period, the files and their row counts, goes up only after every file has uploaded. Export History shows each run's files and result.

04 ·Salesforce sync with Account fields, matched by your own identifier

The Salesforce integration can map Account fields as well as Contact fields. For an Account sync, the admin pairs the platform's user identifier, such as Customer ID, with the Account field that holds the same value. A read applies the matched Account's mapped values to the client, and a write updates mapped fields on that existing Account. The sync never creates Accounts, and it uses the identifier field only for matching, so no outbound mapping can overwrite it. Contact sync can still match by email.

05 ·An Order Status Change event for outgoing webhooks

Outgoing Webhooks have an Order Status Change event. It sends once an order's new status has saved, whether the change came from Order History or the API, and carries the order, the community, and the previous and new status in the same shape for both. An update that leaves the status as it was, or fails, sends nothing. Pointed at a workflow's incoming webhook, the event can start a workflow that checks the new status, for example before passing an order to a fulfilment partner.

06 ·Settings visits in the Audit Log

The Audit Log has a Settings Access category. Each time an owner or admin opens a community settings page, the log records who opened it, the page (and the tab, where one is selected), the time and the IP address. A reload or a return visit counts as a new visit; refreshing a table or changing a filter on the page does not.