Triggers
A trigger is whatever causes a published workflow to run. Which triggers a workflow has is determined by the node you put at the start of it.
A workflow can only be triggered while it is published.
Upload page
The most common starting point. The Local Upload node gives the workflow its own upload page: a link you can share with whoever needs to submit SBOMs. They open it, drop in a file, and a run starts.
The page can carry your own headline and message, and can be set to require sign-in if it should not be open to anyone with the link.
Database polling
The Database Read node watches a database you have registered as a connection and starts a run when there is something to process.
You choose how often it checks — immediately, hourly, daily, weekly, or monthly — and whether it should process only entries added after the workflow was created or work through everything from the beginning.
API
Workflows can be triggered programmatically over the REST API, which is the route to take when another system should start a run: a build pipeline, a release process, or an internal tool.
See Using the API and the API reference.
Choosing a trigger
| If you want to… | Use |
|---|---|
| Let people submit files themselves | An upload page |
| Process data as it lands in a database | Database polling |
| Start runs from another system | The API |
Related
- Executions — what a trigger creates.
- Connections — required for database polling.