# File and record event triggers

Event-driven workflows start when supported data activity occurs. File-added workflows react to newly stored objects; record-ingestion workflows react to data becoming available from processing.

## Configure file processing

Choose **On file**, bind the intended store where the workflow supports a specific connection, and define the file scope. A path pattern can express the intended filename selection. App-managed ingestion uses the app's own document area so unrelated app uploads do not become its input.

Use a narrow prefix or source boundary for important routing decisions. Confirm behavior with one matching and one nonmatching file before enabling a broad process. Existing stored files are not automatically equivalent to new file-added events; run an explicit backfill when you need to process historical content.

An event can contain more than one file. The admitted input should contain the matching subset, and a scope with no matching files should not create useful processing work. Downstream document jobs still need permission to read each file.

## Configure record-driven processing

Choose **Event** for supported ingestion events. Record type describes the intended data, but do not use that label alone as proof of a strict dispatch filter. Bind the expected upstream source where supported, and place a Filter step before a write or model call when record content needs enforcement.

Check the actual event payload available to the workflow. A record event can identify upstream work without passing the complete record list into every root; use an appropriate record-loading source when needed.

## Prevent loops and duplicates

A catch-all workflow that writes derived records can generate further ingestion events. Separate upstream and downstream scopes, use explicit source bindings, and avoid chains that feed their own inputs. File-processing outputs should go to a different scope when output creation can fire the same trigger.

Event delivery can be retried. Use stable record keys and idempotent destinations rather than assuming one event always means one external write.

Test automation with small inputs and inspect run history for repeated or unexpected admissions. See [triggers](/docs/workflows/triggers), [reliability](/docs/workflows/reliability), and [connections](/docs/connections/overview).