Server-Side Action Execution
Where an action executes matters. Actions that run in the browser stop when the browser tab closes, fail when the network drops, and can be interrupted at any step. For simple UI interactions — navigate to a page, show a notification — browser-side execution is fine. For actions that modify data, send emails, or trigger integrations, reliability requires server-side execution.
Complex action chains in Swifty execute server-side.
Why Server-Side Matters
When an action chain runs on the server, it runs to completion regardless of what the user's browser does afterward. The user clicks "Approve," the server receives the request, and the action chain executes:
- Validate required fields
- Update the status field
- Create a payment schedule entry
- Send email notifications to three recipients
- Log an audit entry
Steps 3, 4, and 5 will complete even if the user navigates away immediately after clicking. The browser doesn't need to stay open. The chain doesn't need the browser's cooperation.
Consistent Execution Regardless of Trigger
Action chains triggered by a button click, a lifecycle event, or a scheduled job all execute on the server through the same runtime. The execution environment is identical. A chain that's tested via a button click behaves the same way when triggered automatically by a lifecycle event.
This consistency eliminates a common class of bugs in automation systems — behavior that works through one trigger but fails through another because the execution environment differs.
Atomic Operations
Related steps within an action chain can be grouped as atomic operations. If any step in the group fails, all preceding steps in the group are rolled back. This prevents partial execution states — a record updated but a notification not sent, for example.
Atomic grouping is optional, configured per chain. Chains where steps are independent (one failure shouldn't undo previous successful steps) can execute non-atomically.
Execution Logging
Every action chain execution is logged. The log records when the chain started, which steps were attempted, which succeeded, which failed, what error occurred, and the final outcome. Logs are accessible from the record's activity history and from an administrative execution log.
When something doesn't work as expected, the execution log shows exactly what happened. Debugging is inspection, not guesswork.
Queueing for High-Volume Scenarios
For action chains triggered in high-frequency scenarios — imports, batch operations, high-traffic events — execution is queued rather than synchronous. The user receives immediate acknowledgment; the chain runs as soon as capacity allows. Status is visible in the execution log.