Automations from external hosts
See scheduled jobs that belong to another system, without confusing them with Elyra's routines.
The Automations screen has two groups. The first, Your routines, is Elyra’s. The second, External hosts, shows jobs that are not Elyra’s — they belong to another system, and the app merely presents them.
What the section shows
It only appears when there is an external host configured; with none, the group does not exist on the screen. When it exists, each host reports which state it is in:
| State | What it means |
|---|---|
| Manageable | The app can query and trigger that host’s jobs |
| Read-only | The app shows the jobs, but cannot change them |
| Unavailable | The host did not respond; what appears may be out of date |
Each job brings the schedule, the run history and what it asks for.
What is Elyra’s and what is not
This is the distinction that avoids confusion:
- The schedule, execution, editing and history of an external job belong to that host’s provider. What the app does is a request; the other system decides.
- There is no equivalent command in Elyra’s command line to create or edit these automations.
- Availability depends on the host. An external job may be visible today and unavailable tomorrow, without anything having changed in Elyra.
- There is no promise of synchronization. What you see is what the host reported on the last query.
When to use this section
- To know what already runs in another system before creating a similar routine in Elyra.
- To trigger an external job, when the host allows it.
- To see the history of something that already exists, without switching tools.
Scope and limits
- Do not assume the action will work. A read-only host refuses the change; an unavailable host receives nothing.
- The reading may be stale. Without a response from the host, what is on the screen is the last known state.
- States and host names are not guaranteed across releases — they depend on what each external provider exposes.