> ## Documentation Index
> Fetch the complete documentation index at: https://docs.alumio.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Routes
> A Route connects two systems by combining an Incoming configuration, route transformers, and an Outgoing configuration.
In Alumio, integrations between two systems are built using **Routes**. A Route describes how data moves from a source system into Alumio, how it is transformed, and how it is sent to a destination system.
## **Anatomy of a Route**
Every Route is built from three building blocks:
* An [Incoming configuration](/documentation/integrations/incoming-configurations) that fetches data from a source system.
* Route [transformers](/references/transformer) that shape or enrich the data inside Alumio.
* An [Outgoing configuration](/documentation/integrations/outgoing-configurations) that sends the data to a destination system.
Both the Incoming and Outgoing configurations can also have their own transformers, so a Route has three transformation stages in total: on the Incoming, on the Route itself, and on the Outgoing.
## **How a Route Runs**
A Route runs in two steps:
1. The **Incoming** is executed first. It collects data from the source system. For each item returned, Alumio creates a [Task](/documentation/integrations/tasks) that holds the data for that item.
2. The **Outgoing** is executed next. It picks up the tasks created by the Incoming, runs the outgoing transformers, and sends the data to the destination system.
Tasks move through a status lifecycle (`New`, `Processing`, `Finished`, `Failed`, `Skipped`, `Waiting`). See [Tasks](/documentation/integrations/tasks) for the full lifecycle.
## **Reusing Configurations**
Both Incoming and Outgoing configurations can be used in more than one route. This makes it easy to fan out the same source data to multiple destinations, or to share a destination across several flows.
When the same Incoming configuration is used in multiple Routes, the data is fetched only once. Alumio then duplicates the resulting tasks for each Route that uses the Incoming.
## **Route Options**
A Route exposes several options that control how it runs. You can configure these on the Route detail page.
**Enable task retrying**
When a task fails (for example, the destination API returns an error), Alumio retries the outgoing part of the route on that task. See [Tasks](/documentation/integrations/tasks#failed) for how failed tasks are handled.
**Enable waiting status**
After processing, the task status is set to `Waiting` instead of `Finished`. The task stays in `Waiting` until it is manually moved to `Finished` or `Failed`.
**Enable real-time processing**
The Route automatically runs on each task as soon as the Incoming creates it. With real-time processing enabled, you do not need a [Scheduler](/documentation/integrations/schedulers) on the route.
**Enable parallel processing**
Allows multiple exports to run at the same time. To use this, set up several [Schedulers](/documentation/integrations/schedulers) on the Route. Each Scheduler runs as one parallel process.
Improper configuration may cause race conditions or data inconsistencies, so use this option with care. Parallel processing cannot be combined with real-time processing.
## **Triggering a Route**
A route can be started in several ways:
* A [Scheduler](/documentation/integrations/schedulers) runs the route on a recurring interval. This is the most common setup.
* A [Webhook](/references/webhook) injects data directly into the incoming configuration. The incoming then creates tasks from the webhook payload.
* **Real-time processing** (see above) runs the outgoing automatically as tasks are created.