App Cannot Be Installed Due To A Supersedence Relationship Conflict | Fix It Fast

This message shows up often with Win32 apps in Microsoft Intune when you’re updating a package, replacing an app, or chaining prerequisites. Oddly, the app you clicked may be innocent. A parent app, a dependency, or a retired version can cause the collision.

You don’t need a long hunt here. You need a “one path” plan: install what’s required, remove what must go, then install the target. The steps below start with checks, then move into fixes that stop repeats.

What A Supersedence Relationship Conflict Means In Intune

Supersedence tells Intune how to treat an older app when a newer app is assigned. It can act like an in-place update (the new installer upgrades the old version) or a replace (Intune runs the old uninstall, then installs the new app). Microsoft’s Win32 supersedence guidance explains these two patterns and the “uninstall previous version” option.

The conflict message appears when Intune can’t build one safe route from the device’s current state to the goal state. The relationship graph might contain a loop, two competing “next steps,” or a dependency that could get removed by the same chain that needs it.

Supersedence Vs Dependency Vs Requirements

These features sound similar, but they answer different questions. A dependency says “install this first.” A requirement says “install only if the device matches this rule.” Supersedence says “this newer app should take over from that older app.” The conflict appears when you use more than one of these to control the same version move.

• Use Dependencies For Building Blocks — Runtimes, agents, and shared components fit well here because they can be installed without removing anything.
• Use Requirements For Guardrails — OS version, disk space, architecture, and app presence checks stop bad installs early.
• Use Supersedence For Version Moves — Save it for “v1 to v2” or “old product to new product” moments where the order matters.

Patterns That Trigger The Block

• Opposite targeting — The same device is included in one group that installs a new app and another group that uninstalls a related app at the same time.
• Dependency conflict — Your main app depends on something you’re also replacing through supersedence.
• Looped links — A supersedes B, and B supersedes A, or a longer loop exists.

Where To Look First In Intune

Quick check — You want to find the relationship that’s actually blocking the device, not the one that looks suspicious.

• Open Supersedence And Dependencies — In the app record, review the dependency list and any superseded apps.
• Audit Assignments — Check whether the device sits in multiple groups that pull in opposite directions.
• Use Relationship Viewer If Available — A visual graph can reveal a hidden loop or a dependency that’s also superseded.

If your tenant has many Win32 apps, do a quick “shared components” check too. WebView2 and VC++ packages are common repeat offenders when multiple teams publish their own copies.

Three Questions To Answer In One Minute

• Which App Is The “Owner” — If two app records represent the same product, decide which one should survive long term.
• What’s Installed Right Now — Check the device’s reported apps list and confirm the version that Intune detects, not just what Add/Remove Programs shows.
• What’s The Intended End State — Do you want an upgrade in place, or a full remove and install? That decision drives the supersedence mode.

If you can’t answer those three, pause and map the app family first. It’s faster than pushing changes blind and creating a loop by accident.

App Cannot Be Installed Due To A Supersedence Relationship Conflict

Start by treating this as a routing problem. Your aim is to remove the collision, then let the agent run through the chain without interruptions. The table below maps the most common symptoms to the fix that tends to clear the block.

What You See	What’s Going On	Fix That Works
New version fails as Required, old version still assigned	Targeting asks the device to both move forward and stay put	Move devices to one version group at a time; remove the opposing assignment
Install fails only when dependencies exist	A dependency is part of a replace chain	Pause supersedence on the dependency until the parent app no longer needs it
Replace chain uninstalls, then nothing installs	Uninstall or detection rules don’t match the real device state	Fix uninstall commands, return codes, and detection rules; then re-evaluate

Step 1: Find Dependency And Supersedence Collisions

If the blocked app has dependencies, inspect those first. A dependency with its own supersedence chain can force Intune into a corner, especially when the dependency might be removed during the parent install.

• List Each Dependency — Write down each dependency and whether auto-install is set.
• Check Each Dependency’s Supersedence — Look for “replace” links that uninstall versions still required by other apps.
• Break The Collision — Remove the supersedence link or switch the rollout order so the dependency isn’t being replaced mid-install.

Step 2: Remove Loops And Competing Chains

Supersedence works best as a straight line: v1 → v2 → v3. Problems start when two newer apps both supersede the same older app, or when a link points backward.

• Pick One Chain Owner — If two apps supersede the same app, keep one chain and retire the other.
• Check For Backward Links — Ensure an older entry does not supersede a newer entry anywhere.
• Keep Versions Together — For products updated often, prefer one app record updated in place when the installer supports it.

Step 3: Match “Uninstall Previous Version” To The Installer

Replace mode runs your uninstall command. Update mode assumes the new installer can upgrade over the old version cleanly. A mismatch can leave the device in a half-state where neither version is detected the way Intune expects.

• Choose Update Mode For True Upgrades — Use it when the vendor installer upgrades an existing install without a separate uninstall.
• Choose Replace Mode For Clean Swaps — Use it when you need to remove old bits first, and your uninstall is silent.
• Confirm Detection Behavior — After a test install, confirm the detection rule matches what the installer actually writes.

Step 4: Tighten Detection Rules And Exit Code Handling

Even with a clean graph, a bad detection rule can mimic a conflict. If Intune still detects the old app after uninstall, it may keep trying to reconcile the chain and never move forward.

• Prefer MSI Product Code For MSI Apps — It’s stable and aligns with what Windows reports.
• Use File Or Registry For EXE Installs — Pick a file version or registry value that truly changes on upgrade.
• Handle Reboot Codes — If your installer returns 3010 for “reboot required,” make sure Intune treats it as success so the chain can continue.

Fix App Cannot Be Installed Due To A Supersedence Relationship Conflict In Intune

Deeper fix — If the issue keeps coming back across versions, tighten your rollout design so devices only ever receive one clear instruction per stage.

Stage The Migration With Two Simple Groups

• Create A Current Group — Required install for the newest app version goes here.
• Create A Legacy Group — Keep only the older version here, and move devices out as they migrate.
• Avoid Dual Actions — Don’t assign install and uninstall for related apps to the same devices during the same window.

This keeps the device from receiving “install B” and “uninstall B or A” signals that can collide inside one evaluation cycle.

Standardize Shared Components As Dependencies

Shared runtimes get messy when each product team publishes its own package. Standardize them as a small “platform” set, then depend on them from each app that needs them.

• Pick One Runtime Package — One WebView2, one VC++ set, one Java runtime, based on your estate.
• Make It A Dependency — Attach it as a dependency with auto-install for apps that require it.
• Keep Runtime Supersedence Separate — If you do version supersedence for a runtime, keep it inside that runtime family only.

Use Client Logs To Pinpoint The Blocking App

When the portal message is vague, the device logs show which app object blocked the evaluation. For Win32 apps, start with the Intune Management Extension logs. Microsoft’s documentation lists the default log path and troubleshooting flow for Win32 app installs.

• Open The Log Folder — Go to C:\\ProgramData\\Microsoft\\IntuneManagementExtension\\Logs.
• Search For The Error — In IntuneManagementExtension.log, search for 0x87D300DB and “supersedence relationship conflict”.
• Trace The Chain — Identify the app IDs in the log lines, then inspect those apps’ dependencies and supersedence links in the portal.

If You Also Use Configuration Manager

If you manage apps in Configuration Manager too, watch for the same pattern: a dependency that’s also being superseded. This overview explains the rule collision and safer layouts.

Dependency vs supersedence in Configuration Manager

How To Re-Run The Install Cleanly After Fixes

After you adjust relationships, let devices re-evaluate. If the device keeps showing the old failure, trigger the next check-in and make sure the old version isn’t stuck in a pending uninstall state.

If you used replace mode, confirm the old uninstall removed shortcuts and registry entries, then retry the install after one more sync.

• Sync The Device — Trigger a sync from Company Portal or from the device record in Intune.
• Reboot If You Swapped Modes — A reboot clears pending file operations left behind by MSI and app installers.
• Confirm The Detected State — Verify whether Intune still detects the superseded app, the superseding app, or neither.

If the install fails again, don’t keep tweaking random settings. Go back to the log, confirm which relationship blocked the install, and change only that one piece.

Ways To Prevent Supersedence Conflicts In Future Rollouts

Once this is fixed, a few habits keep it from coming back during the next upgrade cycle.

• Keep One App Record Per Product — Fewer parallel objects means fewer hidden links to trip over.
• Write Detection Rules You Can Trust — Use stable file, registry, or MSI detection that reflects the real installed state.
• Test Against Real Messy Devices — Include devices with older versions, mixed runtimes, and real group memberships.
• Review Relationships Before Broad Targeting — A quick graph scan can reveal a loop before users do.

If you still see the same message after all fixes, re-check for the two classic causes: a dependency being replaced during the parent install, or a targeting clash that asks for two opposing actions. Those two account for most cases where app cannot be installed due to a supersedence relationship conflict appears in Intune.

Official references are Win32 app supersedence, Win32 app troubleshooting, and IME logs.