Skip to main content

​
Upload Trigger

The Upload trigger gives a flow a drop zone. Drop a file into it and the flow runs, with the file stored and attached to the run. It is the simplest trigger in the product: there is nothing to configure. The node has a General tab for its name and ID, and an Upload tab holding the drop zone.
This is not a watch on a storage bucket. Nothing fires when a file appears in your object store by some other route. The trigger fires because the upload itself names the flow — which today means the drop zone on this node.

​
Using it

1

Add an Upload trigger

From the Add Node panel. The editor is titled Upload File Trigger.
2

Open the Upload tab

Drag a file onto the drop zone, or click to choose one.
3

The flow runs

A green confirmation appears: “The file was uploaded successfully and the flow was triggered.”
One file at a time. Uploading several files means several runs, each carrying one file.
There is no progress indicator while the file uploads — the drop zone looks idle until the confirmation appears. Give a large file a moment before assuming nothing happened.

​
Which version of the flow runs

The Trigger Flow toggle offers Draft and Published.
The toggle does nothing. The upload always runs the version of the flow you have open in the editor, whatever the toggle is set to. In practice that means editing a flow and uploading runs the draft; opening the published flow and uploading runs the published one.

​
Where the file goes

Files land in a managed uploads bucket on your account and are deleted after two weeks. There is no way to extend that from the trigger. The stored key is a short random prefix plus your filename — aB3xQ9.invoice.pdf from invoice.pdf. The prefix keeps two uploads of the same name apart.

​
Limits

There is no accepted-file-type list. Any file the drop zone takes is uploaded, and nothing checks the extension or the content type at any point. The drop zone rejects files over 6 MB in the browser. That is a client-side check on this control only — it is not a rule the platform enforces.

​
What the flow receives

$.trigger is exactly two keys:
No metadata is delivered. There is no file name, no MIME type, no size and no upload timestamp in the payload. The original filename survives only as the tail of key, after the random prefix. If a step needs the type, infer it from the extension or read it from the object itself.

​
Getting at the contents

An Assistant step receives the file automatically — it is attached to the run as knowledge, so the assistant can read a PDF, a spreadsheet or an image without any fetch step in between. This is the intended shape for the trigger, and it is why the payload carries so little. Any other step reads the object store by bucket and key:

​
Routing on file type

There is no type field to branch on, so branch on the key:
Give a Condition step a rule over that string — the extension is the last part of it.
What runs after the trigger is decided by each step’s outcome, not by the arrows in the editor. A Condition step’s outcome names the step IDs to run next — one, several (they start at the same time), or the reserved RESOLVE_SUCCESS / RESOLVE_ERROR to end the run. A line drawn between two steps that no outcome names is decoration.

​
Delivery

The upload and the flow run are two separate things, and only the first is confirmed to you.
A successful upload does not guarantee the flow started. The upload is acknowledged as soon as the file is stored; the message that starts the flow is sent afterwards, is best-effort, and is not retried. If it is lost, the file sits in the bucket and nothing runs — with no error on either side.
If a run must not be missed, do not rely on this trigger alone. Put an HTTP Request trigger in front of it, where the caller gets a response and can retry.

​
Troubleshooting

Check Monitoring for a run at that time. If there is none, the trigger message was lost — re-upload the file.
The Draft / Published toggle is inert. Open the version you want to run, then upload.
The drop zone caps at 6 MB.
Check the step is an Assistant step — only those receive the file automatically. Anything else has to read the object store using $.trigger.bucket and $.trigger.key.
Take it from $.trigger.key, after the random prefix and the first full stop.
Files are removed after two weeks. Copy anything the flow needs to keep into your own storage during the run.

​
Next Steps

Assistant Step

Reading the uploaded document

Condition Step

Routing on the file’s extension

Email Trigger

The same pattern, with files arriving as attachments

Triggers Overview

Every way a flow can start