Actions Defined in Configuration
Buttons trigger behavior. The behavior a button triggers is where applications diverge from each other — it's what makes one application different from another with the same data model. In traditional development, that behavior lives in code. In Swifty, it lives in configuration.
Configuration-defined actions mean the full behavior of any button, any action, any triggered automation is expressed as structured data rather than code — readable, changeable, deployable without a development cycle.
A Button's Action Is Its Definition
When you add a button component in the builder, you immediately configure what it does. There's no "wire it up later" — the action definition is part of the button. Select the action type, configure the steps, and the button is complete.
The action definition is stored as configuration alongside the rest of the page definition. It's version-controlled. It can be reviewed in a change history. It can be reverted.
The Full Range of Behavior
Configuration-defined actions can express a wide range of behavior:
- Navigate to any page, with or without record context
- Update fields on the current or related records
- Create records with specified initial field values
- Transition status along a defined workflow
- Send notifications to specified recipients
- Collect input from the user mid-action
- Call external services through configured integrations
- Branch conditionally based on field values
- Confirm before proceeding on destructive operations
Chaining these steps creates sophisticated workflows. The full chain is visible in the builder — no hidden logic, no code to read.
Changes Without Deployments
When a business process changes — a new approval step is added, a notification recipient changes, a status workflow is updated — updating the action configuration reflects the change immediately. No code to write, no deployment to schedule, no waiting period.
This responsiveness to change is one of the most practically significant advantages of configuration-driven behavior. Processes evolve; systems that require code changes to follow process changes fall behind.
Legible to Non-Developers
Configuration-defined actions can be reviewed and understood by non-developers. A product manager auditing a workflow can read the action chain and understand what each button does. They can request changes in specific terms: "Add a step after status update to notify the manager." That specificity is only possible when the behavior is visible and legible.
When Code Is the Right Answer
Configuration covers most workflow needs. For operations that require logic too complex for the available step types — specialized calculations, conditional trees beyond the builder's branching support, integration logic that doesn't fit a standard pattern — custom code remains available through the extension system.
But the bar for reaching for code should be high. Most workflows are expressible in configuration. Starting there saves time and keeps behavior visible.