From ActivityInfo 4.0 webhooks to automations

ActivityInfo 4.0 introduced webhooks: a database could register a URL, and ActivityInfo would post a JSON message to it whenever a record was added, edited, or deleted. Many organizations built integrations on this — notification workflows in Power Automate or Pipedream, synchronization jobs, and the ActivityInfo Power Automate connector itself.

The new automation engine generalizes this idea, and it is worth understanding what changed, what deliberately did not, and how to choose between the webhook payload formats.

What changed

A 4.0 webhook was a single, fixed pipeline: an event, an optional filter formula, and an HTTP request in one fixed format. An automation is a flow of steps: a trigger that produces data, followed by any combination of filter, email, and webhook steps.

The pivotal new concept is step data. Every trigger produces a table — for record triggers, a single row holding the record's fields alongside the reserved _previous, _user, and _trigger columns. Every later step works from that same row: the filter evaluates its condition against it, the email step interpolates it into templates, and the webhook step can serialize it or interpolate it into a custom body. One data model, learned once, used everywhere — and it is the same formula language used across ActivityInfo for calculated fields and measures.

This is also why filters became more capable: a 4.0 filter formula could only see the record itself, whereas a filter step can compare against the pre-edit snapshot (_previous.STATUS != STATUS), navigate references (CLINIC.NAME == "Mangina Health Post"), and inspect the actor (_user.email).

Imports now fire triggers

ActivityInfo 4.0 webhooks did not fire for changes arising from imports. The exclusion was meant to protect receiving systems from bursts, but in practice it created real problems: records imported in bulk silently bypassed the workflows built on webhooks, and consumers could never rely on having seen every change. Automations remove the exclusion — record triggers fire for every change, whatever its origin: data entry, the mobile app, the API, and imports alike, one run per record.

This is a behavioral change for migrated webhooks: an automation migrated from a 4.0 webhook starts receiving events for imported records too. If your receiving system cannot absorb a burst of one request per imported record, add a filter step to narrow which events proceed, or adapt the receiver to queue incoming requests.

What deliberately did not change

Existing webhooks keep working, byte for byte. A webhook created in ActivityInfo 4.0 appears in the new editor as an automation — a record trigger, your filter formula if you had one, and a webhook step — and its payload format is ActivityInfo 4.0-compatible: the exact JSON shape 4.0 produced, maintained as a published contract and pinned by a regression suite against a snapshot of production events. Integrations built against 4.0 webhooks, including flows using the Power Automate connector, keep working without changes to the payload they receive — the one behavioral difference is that imports now fire events too, as described above.

Signing also carries over unchanged: the same standard-webhooks headers and the same v1 HMAC-SHA256 signature scheme, computed over the exact request body.

Why new payload formats at all

The 4.0 format is event-oriented: its update body carries only the fields changed by the event, and its field values were designed for the 4.0 data model. That makes it precise for change-tracking, but awkward for two common cases:

• "Just give me the record." Consumers that want the record's full current state had to merge update into previous themselves — and calculated fields were missing entirely, because the 4.0 format is built from the record's stored values and calculated fields are computed on read. The Standard format sends the trigger's step data instead: every field of the form on every event, calculated fields included, in a stable shape, with _previous, _user, and _trigger alongside — exactly what formulas see, so what you test in a filter is what your consumer receives.

• "The receiver dictates the format." Chat tools and many APIs require a specific body. Previously this meant an intermediary service just to reshape JSON. The Custom format removes that hop: you write the body as a template with ${...} references, and ActivityInfo fills in the values — JSON-escaped, so the document stays valid whatever the data contains. A Google Chat notification becomes a single webhook step with a one-line template.

Choosing a format

Migrated webhooks and Power Automate connections keep the ActivityInfo 4.0-compatible format, so nothing changes for existing integrations; new webhook steps default to Standard. The format is a per-step setting, so you can add a Standard or Custom webhook alongside an existing 4.0-compatible one and migrate consumers at your own pace.

See also

• Webhook step
• Understanding Automations in ActivityInfo