A Dependency in Catalio is something an Initiative depends on before it can proceed — either work that must be done by another initiative inside your organization, or a commitment that must be delivered by an external team, vendor, or system. Dependencies are tracked alongside tasks, risks, and metrics as first-class elements of initiative governance.
Unlike Initiative Risks, which track things that might go wrong, Dependencies track concrete things that must happen. A dependency is a known external prerequisite; a risk is an uncertain threat.
Dependency Types
Catalio supports two dependency types:
| Type | When to Use |
|---|---|
| internal | Work owned by another Initiative in your organization. Can be linked to that Initiative. |
| external | Work owned by a vendor, partner team, or external system outside your organization. |
For internal dependencies, you can optionally link the blocking_initiative — the specific
other Initiative that must deliver the work. This link creates a visible cross-initiative
dependency graph and makes it easy to navigate between related Initiatives.
Status Tracking
Every dependency has a status that tracks how resolution is progressing:
| Status | Meaning |
|---|---|
| not_started | Dependency identified but no resolution work has begun (default) |
| in_progress | Work is underway to resolve the dependency |
| done | Dependency has been resolved; this Initiative can proceed |
| at_risk | Resolution is at risk — likely needs escalation |
Blocking Flag
The blocking boolean distinguishes critical dependencies from informational ones:
- blocking: true — This dependency must be resolved before the Initiative can advance to the next stage. Catalio surfaces active blocking dependencies as an unmet readiness signal during stage advancement.
- blocking: false — This dependency is tracked for awareness but does not gate advancement.
Use blocking sparingly. If every dependency is blocking, the signal loses meaning. Reserve
blocking: true for dependencies that genuinely prevent the team from proceeding — not just
things that would be nice to have resolved.
Key Fields
| Field | Purpose |
|---|---|
| name | Short name identifying the dependency, e.g. “Journey model shared ownership refactor” |
| description | Detailed explanation of what the dependency is and why it matters |
| owner | Free-text owner, e.g. “Platform Eng Team” — not always a Catalio user |
| status | Current resolution status (see above) |
| blocking | Whether this dependency gates Initiative stage advancement |
| dependency_type | :internal or :external |
| sort_order | Display ordering within the dependency list (lower numbers appear first) |
| blocking_initiative | For internal dependencies: the linked Initiative that must deliver the work |
Dependencies in the Initiative Lifecycle
Dependencies are relevant at every stage of an Initiative:
| Stage | Dependency Focus |
|---|---|
| planning | Identify all known dependencies early; classify as blocking or informational |
| approval | All blocking dependencies should be cleared or have confirmed resolution plans |
| build | Actively track in_progress dependencies; escalate at_risk ones quickly |
| retro | Review how dependency resolution impacted delivery; note patterns |
During approval → build advancement, Catalio’s readiness signals flag any dependencies with
blocking: true and status != :done. This gives sponsors a clear picture of outstanding
commitments before the team enters active build.
Relationships at a Glance
| Related Concept | Relationship |
|---|---|
| Initiative | Dependencies belong to an Initiative |
| Initiative Risks | Related concept for uncertain threats vs. known deps |
| Initiative Tasks | Resolution actions are tracked as Tasks |
Best Practices
Name dependencies precisely.
“API dependency” is too vague. “Order management API v2 endpoints from Payments team” is actionable — the team knows exactly what to track and who owns it.
Set the owner even when it’s ambiguous.
If you don’t know the specific person, use the team name. An unknown owner is a dependency at risk. Recording something — even “TBD: Platform Eng” — is better than leaving it blank.
Separate internal from external early.
Internal dependencies can be resolved through cross-team coordination within your organization. External dependencies may require contracts, SLAs, or vendor commitments. Knowing which is which shapes how you escalate.
Escalate at_risk dependencies immediately.
A dependency that slips from in_progress to at_risk is a signal to act, not wait. Update the
status and communicate to stakeholders — the audit trail is there, but only if you use it.
Don’t block everything.
Mark blocking: true only for dependencies that genuinely prevent the team from starting or
completing a stage. Informational dependencies should stay blocking: false so the readiness
signals remain meaningful.
Next Steps
- Understand Initiatives — Learn the governance lifecycle Dependencies participate in
- Manage Risks — Track uncertain threats alongside known Dependencies
- Create Initiative Tasks — Convert resolution actions into delivery work items
Pro Tip: Create dependencies as soon as you know about them, even if resolution is weeks away. An untracked dependency discovered late in Build is far more disruptive than one captured in Planning and monitored throughout. The earlier you name it, the earlier the team can act.
Support
- Documentation: Continue reading about Initiative Risks and Metrics
- In-App Help: The AI assistant can help you identify dependencies from Initiative context
- Email: support@catalio.ai
- Community: Share dependency management patterns with other Catalio users