> ## 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.

# Overview

> An overview of how Alumio moves data between systems using routes, configurations, and tasks.

**Integrations** define how data flows between systems in Alumio. Each integration is built from four components: a Route that connects everything together, an Incoming configuration that fetches the data, an Outgoing configuration that sends it to the destination, and a Scheduler that triggers the whole flow automatically.

Navigate to **Integrations** in the top navigation to access Routes, Incoming, Outgoing, and Schedulers.

### What integrations are

An integration in Alumio is a configured data flow between a source system and a destination system. Instead of building point-to-point connections, Alumio breaks each integration into reusable components that can be combined, tested, and monitored independently.

A typical integration flow looks like this:

**Scheduler** triggers the **Route** → **Incoming** fetches data and creates tasks → **Outgoing** picks up tasks and sends data to the destination.

### Setting up a Route

A Route is the backbone of an integration. It connects an Incoming configuration, an Outgoing configuration, and a Scheduler, and controls how data moves from source to destination.

To set up a Route, you need three things in place first:

* An **Incoming configuration** that defines where data comes from and how it is fetched.
* An **Outgoing configuration** that defines where data goes and how it is sent.
* A **Scheduler** that defines when the Route runs.

### Seeing your first results

Once a Route has run, results are visible as tasks. A task is one unit of work created by the Incoming for each item it returns. Tasks are the best place to verify that your integration is working correctly.

Navigate to **Tasks** in the top navigation to see all tasks across your environment. Each task shows:

* The entity data is returned by the Incoming after the transformers have run.
* The current status: `New`, `Processing`, `Finished`, `Failed`, `Skipped`, or `Waiting`.
* Logs for that task, including any error messages.

If tasks are showing a `Failed` status, the logs on the task will indicate what went wrong -- for example, a `500` error from the destination API or a transformer misconfiguration.

### Why you need a Scheduler

Without a Scheduler, a Route does not run automatically. A Scheduler defines the interval at which a Route is triggered, for example, every 5 minutes, hourly, or once a day.

Schedulers are what make integrations continuous. Instead of manually triggering a Route each time, the Scheduler ensures data is fetched and processed on a predictable cadence. For event-driven integrations where the source system pushes data, a Webhook can replace the Scheduler as the trigger.

Each Scheduler is linked to one Route. If you need the same data flow to run on multiple schedules, create separate Schedulers and link each one to its own Route.