Actions Best Practices

Chain operations in dependency order

A downstream action only starts when its parent succeeds, so order the chain the way the data flows, such as a Sync before the Profile and Scan that rely on the fresh schema. A failure upstream then skips the dependents instead of measuring stale data.

Plan around the 10-Operation cap

A Flow accepts at most 10 Operation actions. When a pipeline grows past that, split it into two Flows chained by an Operation Completed trigger instead of cramming everything behind one trigger.

Initialize the datastore first

The Datastore dropdown lists initialized datastores: source datastores need successful Sync, Profile, and Scan runs; enrichment datastores need Sync and Profile. Export and Materialize additionally need an enrichment destination connected to the source. Run those operations manually, and link the destination, before automating them.

Bound the volume

Use the record limits on Scan and Materialize actions to keep automated runs from processing more data than the schedule needs.

Archive before you delete

Archive keeps the record for audits and can be reviewed later, while Delete is permanent. Reserve Delete for noise you are certain nobody will need.

Pick an inactivity period longer than your triage cycle

The action only touches anomalies with no updates or comments for the full period. If the team reviews findings monthly, a 30-day period would clean up anomalies that are simply next in line; give it margin.

Tag what the automation touches

Assign a tag such as auto-archived on the Archive action, so automated cleanups stay distinguishable from human decisions.

Announce the cleanup

Chain a notification after the action with the {{anomaly_count}} and {{inactivity_timeframe}} tokens, so the team sees how much each run removed.

Filter the trigger before it can flood

There is no cap on how many notifications a Flow can send, and event-based triggers run once per matching event, so an unfiltered Anomaly Detected trigger messages the channel once per anomaly. Narrow the trigger with a minimum severity, datastores, and statuses, and set Operation Status to Failure on completion alerts, so every message is one someone would act on.

Pick the channel by audience

Use PagerDuty for events someone must act on now, Slack or Teams for team awareness, Email for stakeholders outside the platform, and In App for the people already working in Qualytics.

Test before you publish

Email, Slack, Microsoft Teams and PagerDuty offer a Test Notification button that sends a sample message with dummy data. Confirm the destination, the formatting, and the tokens before the first real event does it for you. In App has no test, so check the bell icon after the Flow's first run.

Put context in the message

Use tokens such as {{datastore_name}} and {{anomaly_message}} so responders understand the event without opening the platform first. The autocomplete only offers tokens valid for the Flow's trigger.

Remember the branch ends here

No action can be chained after a notification. Place it last, and use sibling branches when the same trigger must also run operations.

Authenticate the destination

Use the HTTP Action's auth types (Bearer, Basic, Digest) or the n8n Webhook Secret so the receiving system can trust that calls come from Qualytics.

Test the endpoint before publishing

The Test Workflow button confirms the URL is reachable and correctly formatted before the Flow goes live.

Let the payload do the work

An n8n action posts a structured JSON payload carrying the Flow, the datastore, and the event's context, so build the external automation to read from it instead of hardcoding values. A Webhook sends the rendered message, and an HTTP Action the shape its own settings define.

Remember the branch ends here

Like notifications, workflow actions accept no children. Anything that must run regardless belongs on a sibling branch.

Filter the trigger before opening tickets

A Create Ticket action on an unfiltered Anomaly Detected trigger turns every finding into a ticket. Set a minimum severity and narrow the datastores so each ticket is worth triaging.

Pair creation with a status update

Match the Flow that creates tickets with a second Flow on Anomaly Status Changed running Update Ticket Status, so the tracker closes tickets when the anomalies resolve.

Carry the ticket into the conversation

Chain a notification after the ticketing action using the {{ticket_number}} and {{ticket_url}} tokens, so the team learns about the new ticket where it already talks.

Keep the integration healthy

The action fails when the ticketing integration is unavailable, so treat integration credentials as part of the Flow's upkeep.