A Gate with condition type File Exists already pauses or stops a run that's waiting on a file -- see Gates for every other condition type and how Pause/Stop and job-level/step-level scoping work. The same kind of gate can also decide whether a run gets started in the first place -- Worker checks every active job's Start-scope gates on its regular poll, and the moment a watched file shows up, it enqueues a run for that job right then, instead of waiting on a recurring Schedule. A job can use one or the other to start on its own, never both.

Creating the gate

Under Admin -> Gates, add a gate with Condition Type File Exists, and you'll see a new On Trigger section:

On Trigger is optional -- leave it None and the gate just watches. Pick an action and Worker handles the watched file itself, automatically, before anything else runs: Delete, Move (into a Destination Folder, optionally relative to the file's own folder), or Rename (Literal, or Append a timestamp so two firings can never collide).

Attaching it to a job, with Start scope

Open a job's Gates dialog and attach the gate. When scoped to (Whole Job) and the gate is a File Exists gate, a Trigger choice appears:

Continue (default) pauses/resumes a run already in flight when the file shows up. Start creates a run the moment the file shows up -- only offered when attaching at the whole-job level.

Worked scenario

A vendor drops a CSV into a landing folder at unpredictable times, and you want it processed the moment it arrives: add a File Exists gate watching the landing path with On Trigger Move (into a Processing subfolder), attach it to the job with Trigger set to Start, then add a MoveFile step to file the processed file away for good. No schedule needed on this job at all -- the file arriving is the schedule.