AutoSys Job Dependencies and Conditions — Controlling Job Chains
- AutoSys provides four condition types: success(), failure(), done(), and notrunning()
- done() is the right choice for cleanup or notification jobs that must run regardless of the upstream job's outcome
- Conditions can reference jobs in other boxes or boxes themselves
Dependency management is AutoSys's superpower — the thing that justifies its cost over cron. The condition attribute lets you express exactly what must be true before a job can start. You can chain hundreds of jobs with precise dependency rules, and AutoSys handles the orchestration automatically.
This article covers all condition types, how to combine them, and the gotchas that cause dependency chains to break in production.
The four condition functions
AutoSys provides four functions for expressing job conditions:
/* success(job) — run after job_a completes successfully */ condition: success(job_a) /* failure(job) — run after job_a fails (error handling job) */ condition: failure(job_a) /* done(job) — run after job_a is done, regardless of success or failure */ condition: done(job_a) /* notrunning(job) — run when job_a is NOT currently running */ condition: notrunning(job_a) /* Combining conditions with AND */ condition: success(job_a) AND success(job_b) /* Combining with OR */ condition: success(job_a) OR success(job_b) /* Complex condition */ condition: success(job_a) AND (success(job_b) OR success(job_c))
Cross-box dependencies
Conditions can reference jobs in other boxes or standalone jobs. This lets you build workflows that span multiple boxes.
/* Job in reporting_box waits for a job in etl_box */ insert_job: generate_daily_report job_type: CMD box_name: reporting_box command: /scripts/daily_report.sh machine: report-server owner: batch condition: success(etl_load_job) /* etl_load_job is in etl_box */
The done() condition and why it matters
done() is often overlooked but very useful. It lets a job run after another job completes regardless of whether that job succeeded or failed. This is perfect for cleanup or notification jobs that should always run.
/* Cleanup job: runs whether or not main job succeeded */ insert_job: cleanup_temp_files job_type: CMD command: /scripts/cleanup.sh machine: server01 owner: batch condition: done(main_etl_job) /* runs regardless of main_etl_job outcome */ /* Notification job: always sends status email */ insert_job: send_batch_status_email job_type: CMD command: "/scripts/notify.sh --job main_etl_job" machine: server01 owner: batch condition: done(main_etl_job)
| Condition | Triggers when... | Common use case |
|---|---|---|
| success(job) | Job completed with exit code 0 | Normal sequential dependency |
| failure(job) | Job completed with non-zero exit code | Error handling / failover job |
| done(job) | Job completed (either success or failure) | Cleanup / notification jobs |
| notrunning(job) | Job is not currently RUNNING | Preventing concurrent execution |
🎯 Key Takeaways
- AutoSys provides four condition types: success(), failure(), done(), and notrunning()
- done() is the right choice for cleanup or notification jobs that must run regardless of the upstream job's outcome
- Conditions can reference jobs in other boxes or boxes themselves
- AND/OR logic lets you build complex dependency rules — test them carefully before deploying to production
⚠ Common Mistakes to Avoid
- ✕Using success() when you actually want done() for cleanup jobs — cleanup won't run if the main job fails
- ✕Not accounting for conditions referencing jobs in the INACTIVE state — a job in INACTIVE hasn't run yet, so success() on it is false
- ✕Creating circular dependencies (Job A depends on B, Job B depends on A) — AutoSys won't detect these at definition time; they'll just deadlock
- ✕Forgetting that OR conditions mean the job starts when either side is true — be careful about unintended early triggering
Interview Questions on This Topic
- QWhat is the difference between success() and done() conditions in AutoSys?
- QWhat does the condition: failure() do?
- QCan an AutoSys job condition reference jobs in a different box?
- QWhat happens if you have a circular dependency in AutoSys conditions?
- QWhat condition would you use for a cleanup job that must run whether or not the main job succeeded?
Frequently Asked Questions
What conditions can I use in AutoSys?
AutoSys provides four condition functions: success(job) — job completed successfully; failure(job) — job failed; done(job) — job completed regardless of outcome; notrunning(job) — job is not currently running. You can combine these with AND and OR operators.
What is the done() condition in AutoSys?
done() triggers when a job has completed, whether it succeeded or failed. It's commonly used for cleanup jobs, status notification jobs, or any job that should always run after an upstream job finishes, regardless of outcome.
Can AutoSys job conditions span multiple boxes?
Yes. The condition attribute can reference any job in the AutoSys instance, regardless of which box it belongs to. The referenced job name must be unique across the instance.
What happens if I create a circular dependency in AutoSys?
AutoSys won't detect circular dependencies at job definition time. The jobs will deadlock — Job A waits for B, Job B waits for A, and neither ever starts. You need to carefully review dependency chains to prevent this.
How do I make a job run after any one of several jobs succeeds?
Use OR in your condition: condition: success(job_a) OR success(job_b). The job starts as soon as either condition becomes true.
Developer and founder of TheCodeForge. I built this site because I was tired of tutorials that explain what to type without explaining why it works. Every article here is written to make concepts actually click.