Abort Server Call¶

The Abort Server Call action suppresses a mobile analytics hit entirely — the mobile equivalent of Adobe's s.abort variable on web. When this action fires, Airlock drops the event — no Airlock Processed Track event is dispatched and no Analytics hit is sent.

Screenshot needed

Capture: The Abort Server Call action UI in Launch.

What it does¶

When a rule containing this action fires, the originating track event is consumed and discarded. Nothing is forwarded to Adobe Analytics. No downstream rules fire on this event.

This is unconditional — the action always suppresses when it fires. Use Launch rule conditions to control when the rule fires in the first place.

When to use this action¶

Scenario	Why Abort Server Call rather than something else
Suppress internal or QA device hits	Condition on a device ID or contextdata flag; simpler than writing a JS script that returns null
Drop events from a specific app version	Condition on the app version string
Suppress duplicate hits that slipped through the data layer	Condition on a contextdata key that marks known duplicates
Temporarily pause tracking for a specific event type	Disable the action (via Enabled toggle) without deleting the rule

Abort Server Call vs. returning `null` from a JS script¶

Both approaches suppress the hit. The difference is where the suppression logic lives:

	Abort Server Call	JS `return null`
Logic location	Launch rule conditions	JavaScript script body
Requires scripting	No	Yes
Best for	Simple, condition-based suppression	Suppression that depends on runtime computation (e.g. evaluating a threshold, parsing a value)

If the suppression condition is expressible as a Launch rule condition (equality, contains, regex), use Abort Server Call — it's faster to configure and easier for non-developers to read. If the condition requires code, use Evaluate JavaScript Rules with return null.

Pairing with an Airlock action — the canonical pattern¶

Abort Server Call is most useful stacked on the same rule as another Airlock action. The Airlock action dispatches an enriched Airlock Processed Track event (picked up by Rule B); Abort then suppresses the original event before Analytics processes it. The result is a single, enriched beacon — exactly the outcome the two-rule pattern is designed to produce.

A typical Rule A:

Order	Action
1	Airlock → Evaluate JavaScript Rules (or Set Serialized Events, Product String Builder, …)
2	Airlock → Abort Server Call

Without the Abort step, Analytics still sees the original event in parallel with the enriched dispatch — producing two beacons per app event. See How It Works → Why the second beacon happens for the full beacon flow.

The Enabled toggle¶

Each action has an Enabled checkbox. Unchecking it disables the suppression without deleting the rule — useful for temporarily re-enabling a hit type during debugging.