What are Autotask project dependencies?

In Autotask, project dependencies are links between tasks that control the order work happens — a successor task can't start until its predecessor is complete. They let you sequence a project so the timeline reflects real prerequisites (you can't rack the switch before it ships). Per Autotask's documentation, these dependencies are finish-to-start (FS) only.

How they work

Inside a project's task list or Gantt view, you set one task as dependent on another. Autotask then treats the predecessor's completion as the gate for the successor. This keeps the workplan honest and helps dates roll forward when you shift a phase, so the plan reflects what genuinely has to happen in what order.

The limits to plan around

• Finish-to-start only: no native start-to-start, finish-to-finish, or start-to-finish relationships, and no lead/lag offsets.
• No critical-path readout: dependencies draw the sequence but don't compute the longest chain or flag what will slip your go-live date.
• Cross-project dependency edges are awkward, and there's limited automatic recasting when reality moves under the plan.

If you need richer sequencing

Current adds a dependency layer on top of your PSA — Autotask, ConnectWise, or Halo PSA — which stays your billing source of truth. You get an interactive dependency map, a native critical-path engine, client-side cycle detection so you can't create impossible loops, and PTO-aware back-scheduling that reflows dates around real availability. You model the plan in Current; time still flows to your PSA for billing.

The four relationship types, and why three are missing

Project scheduling recognizes four ways two tasks can relate. Finish-to-start is the familiar one: B waits for A to finish. Start-to-start means B can begin once A begins, which is how parallel workstreams with a shared trigger actually behave. Finish-to-finish means two tasks must complete together, common when a cutover and its verification have to land at the same moment. Start-to-finish is rare but real, mostly in shift handovers.

Autotask offers finish-to-start only. That forces genuinely parallel work into an artificial queue, which is why Autotask project plans tend to look more sequential than the work really is, and why they finish later on paper than the team knows they will in practice.

The offset problem

The other missing piece is lead and lag. Real plans need statements like begin the migration two working days after the tenant build completes, allowing for propagation, or start user training three days before go-live. Without offsets you either create filler tasks to represent waiting, which clutters the plan, or you fudge the dates by hand, which breaks the moment anything moves.

What this costs you in practice

• Plans read as more sequential than the work is, so forecast dates are pessimistic and get ignored.
• Waiting periods become fake tasks, and the plan stops resembling the work.
• When one task slips, nothing recalculates downstream, so the slip is discovered at the status call.
• Cross-project relationships are awkward, so a shared engineer's other commitments are invisible.

How Current models it

Current holds all four types with lead and lag in working days, and the relationships live in Current rather than syncing to the PSA, because Autotask has no field to receive them. Move one task and Current previews every downstream date change before applying it. Cycles are prevented as you draw an edge rather than reported afterwards. The dependency map is an interactive graph you can drag, not a static picture, and it runs the same diagnostics the timeline does so both surfaces agree about what is wrong.