Choose the trigger that matches the handoff
A nightly export, a vendor delivery and an approved software build need different start conditions. A clock-based job asks whether it is time to run. An event-driven job asks whether a particular state change has occurred. A watch-folder workflow observes files and needs a rule for deciding when they are ready. None of these approaches alone proves that the workload is complete or safe to consume.
| Approach | Good fit | Main risk to address |
|---|---|---|
| Scheduled | Predictable reporting or off-hours delivery | Source files arrive late or the previous run is still active |
| Watch folder | Files produced into a known local or network directory | A file is detected while it is still being written |
| Event-driven | Variable arrival time with a meaningful readiness event | Duplicate, missing or out-of-order notifications |
| Hybrid | Prompt processing plus a periodic reconciliation check | Two triggers start the same work |
Define readiness separately from arrival
For a folder, agree how the producer signals completion: a manifest, a completion marker, an appropriate rename convention or a supported stability check. Verify the convention on the actual filesystem. A file whose size stops changing briefly may still be incomplete, so a quiet period should not be treated as universal proof.
For a package workflow, use the documented state that satisfies your handoff requirement. Package creation can precede upload completion, and upload completion can precede recipient download. Ripton's package.status_changed and delivery.status_changed events describe changes; consumers must inspect the relevant state rather than treating every event as success.
Write the failure contract before the happy path
- Choose a stable job or package identifier and make repeated processing safe.
- Set a bounded retry policy and distinguish a temporary outage from invalid credentials or denied access.
- Decide whether overlapping scheduled runs queue, skip or fail; record which behavior occurred.
- Specify the timezone and test daylight-saving transitions where a local-time schedule is used.
- Keep enough source and staging capacity for delayed jobs, and name the person who handles a failed delivery.
- Reconcile expected work with completed work; a notification channel is not the sole record of truth.
Example: a vendor delivery with a deadline
- 1The vendor uploads a package into the agreed receiving workflow.
- 2The receiving process checks the documented completion state and expected file manifest.
- 3A verified event starts downstream work once for that package identifier.
- 4A periodic reconciliation checks for completed packages that were not processed.
- 5An operator receives actionable details when delivery or processing misses its deadline.
This is a design pattern to validate, not a claim that one product performs every downstream step. Keep transfer state, notification receipt and business processing in separate records so a retry cannot silently create a second import.
Evaluate the supported Ripton workflow
Ripton's automation surface documents watch folders, schedules, package pipelines, run history and webhooks. Verify the trigger and execution path in your installed release. A release calendar may control package availability rather than the start of byte movement. Ripton is not presented as a universal business-workflow engine or a packaged public SDK.
- Ripton API and webhook walkthrough
Package creation fields, event semantics and receiver checks.
- GoAnywhere automation documentation
Primary vendor reference illustrating scheduler, file-monitor and event-trigger approaches; not a feature-equivalence claim.