Intune Application Dependencies vs Supersedence: When Should You Use Each?

Both dependencies and supersedence live in the same "App relationships" section of a Win32 app's properties in Intune. Both involve pointing one app at another. And that surface similarity is exactly why people reach for the wrong one, then spend an afternoon debugging a failure that has nothing to do with what they think broke.

They solve two completely different problems. Once you see the actual distinction, you'll never confuse them again.

Application A                    Old Version
     ↓                                ↓
 Dependency        vs.          Supersedence
     ↓                                ↓
Application B                   New Version

The One-Sentence Distinction

A dependency is a relationship between two different apps that both need to exist on a device at the same time. Supersedence is a relationship between two versions of what is, conceptually, the same app across time.

Put another way: dependency is a spatial relationship, two things side by side, both present right now. Supersedence is a temporal relationship, one thing replacing another as time moves forward. Confusing them means asking Intune to solve a "these two things need to coexist" problem with a tool built for "this thing replaces that thing," or the reverse.

Dependencies: The Mechanics

A dependency says: Application A cannot function without Application B, so make sure B exists before A installs.

Application A
     ↓
 Dependency
     ↓
Application B

The load-bearing setting here is Automatically Install:

Dependencies chain. If B itself depends on C, Intune resolves the full graph and installs C, then B, then A, in the correct order, automatically. A real example: an internal line-of-business app (A) that requires a specific Visual C++ Redistributable (B), which in turn might need a Windows feature enabled (C).

Two hard limits worth knowing:

• Up to 100 dependencies, but that ceiling applies to the entire combined dependency graph across every app that shares any part of it, not 100 per individual app. A tenant with a lot of shared prerequisite apps (the same redistributable required by a dozen LOB apps) can hit this ceiling collectively faster than it looks.
• Circular dependencies are rejected outright. If A depends on B and B depends on A, Intune tells you so directly rather than allowing a broken deployment to attempt to resolve an impossible chain.

Supersedence: The Mechanics

Supersedence says: this new package is the successor to that old one, whether it's a version bump or a full replacement.

Old Version
     ↓
Supersedence
     ↓
New Version

There are two distinct flavours, controlled by the "Uninstall previous version" toggle:

Supersedence relationships chain too, up to 10 apps deep in a single chain, letting you build a real version history (v1 superseded by v2, superseded by v3) rather than only ever pointing at the immediately previous release.

The Decision Framework

Two questions, in order, settle almost every case:

Failure Modes Worth Knowing Before You Hit Them

A missed dependency looks nothing like a detection rule failure, but gets triaged the same way. If you've read my post on why detection rules lie, you already know to check MSI product codes and registry redirection first. But a dependency failure is a completely different report entry: the app was never attempted at all, with an explicit "dependency not met" reason. Checking detection rule mechanics for a problem that's actually a missing or mis-toggled dependency wastes time chasing the wrong stage entirely.

Circular dependencies are caught. Circular confusion between dependency and supersedence isn't automatically caught in the same way. Nothing stops you from trying to structure what should be a version relationship as a dependency instead, Intune just won't do what you expect, because you're asking a "these coexist" tool to express a "this replaces that" relationship.

The 100-dependency ceiling is a shared tenant resource, not a per-app budget. If your organisation packages many small internal tools that all depend on the same handful of shared runtimes, model that shared graph deliberately rather than discovering the ceiling by accident during a busy quarter of app onboarding.

Putting It Together

Both features exist because a single Win32 app object is a snapshot: one installer, one detection rule, one set of requirements. Dependencies let that snapshot lean on other snapshots it needs beside it. Supersedence lets a sequence of snapshots represent one thing changing over time. Once that's the mental model, the menu that groups them together stops being confusing, they were never really doing the same job.

Have you hit the shared dependency-graph ceiling, or a supersedence "Update" that quietly left two versions installed? I'd like to hear the specifics. Drop a comment below.