The short answer
A device can use both Intune and Configuration Manager. That does not mean one service owns every setting. Start with the particular task, the device in question and the evidence available for each. Ask your authorized support team to confirm whether co-management applies before interpreting its workload settings.
Keep these questions separate
What is configured? What is actually evidenced?
Configured responsibility
Which workload setting and pilot scope are intended to apply?
Record the configuration source and time. Keep the relevant device membership unknown until confirmed.
Observed device evidence
What enrollment, policy or deployment evidence matches this device and task?
Record the evidence source and time. Configuration alone does not establish what the device received.
These are investigation questions, not a live status report or a policy-precedence diagram.
Four checks that make the question answerable
- Name the responsibility. Write “Windows Update policies,” “client apps” or the exact setting you are investigating, rather than “Who manages this laptop?” Record the expected result and what you observed. Do not guess the workload from the symptom.
- Check the configured scope with an authorized administrator. For the relevant co-management workload, distinguish Configuration Manager, Pilot Intune and Intune. Pilot Intune applies to the selected pilot collection; different workloads can have different pilot collections. Record whether this device belongs to the relevant collection, with the observation date. A pilot for apps does not establish the Windows Update owner.
- Compare configuration with device evidence. Ask support to confirm co-management/enrollment status and the relevant policy evidence for this device. A deployment-policy count alone does not prove Intune enrollment. Keep configured intent, device evidence and unresolved differences separate; an unavailable record is unknown, not a failed deployment.
- Check the exception before declaring a conflict. Client-app management is not an exclusive switch that makes every Configuration Manager app disappear. Company Portal can also be configured to display Configuration Manager apps, so the portal alone is not ownership proof. Device configuration can have explicitly configured Configuration Manager baseline exceptions. Ask which exact deployment or baseline produced the observed result; do not change it to test a guess.
Keep a useful next step
Workload responsibility note
- Use this when
- Intune and Configuration Manager responsibility is unclear for a particular task.
- Leave with
- One workload question, its configured scope, the missing device evidence and a next support owner.
Illustrative example · Not a client result
An admin sees an app in Company Portal and assumes Intune owns updates too. The useful next question is narrower: “For this device, what is the configured Windows Update workload scope, and what device evidence supports it?” App visibility does not settle that question. Pilot membership, policy evidence and the cause of the update symptom remain unverified until checked.
An original Winhoven template. Complete it privately in your approved support workspace. Keep identifiers, collection exports and raw logs out of a public inquiry.
Read or select the template here
WORKLOAD RESPONSIBILITY NOTE Purpose: establish the question and evidence; not approve a change. Task or exact setting being investigated: Expected result / observed behavior: Observation time + time zone: Device reference retained in approved private support workspace: AUTHORIZED SUPPORT COMPARISON Relevant workload (confirmed / still unknown): Configured setting: Configuration Manager / Pilot Intune / Intune / Unknown Configuration source and observation time: Relevant pilot collection, if applicable (private reference): This device's membership confirmed? Yes / No / Unknown; checked at: Co-management/enrollment evidence source and time: Relevant device policy/deployment evidence source and time: Specific application/baseline exception checked? Result / Not applicable / Unknown What is configured versus what is actually evidenced: NEXT HANDOFF Facts established: Unknowns and evidence still needed: Next authorized read-only check and owner: Approved channel for detailed evidence: No management, access or device change is authorized by this note.
Need help clarifying the management path?
Describe the task, what you expected and which responsibility is unclear. You can start with a conversation; the worksheet is optional.
Talk through the endpoint problemBring the question, not a proposed migration.
This guide does not establish your tenant’s effective authority, grant access or authorize a workload move, collection change, baseline exception, policy removal, enrollment change or forced synchronization. Missing configuration or device evidence remains unknown.
Sources for this guide
Understand workload boundaries and exceptionshttps://learn.microsoft.com/en-us/intune/configmgr/comanage/workloads (external, new tab)
Review the workload definitions, client-app coexistence and explicitly configured baseline exceptions.
Understand configured workload and pilot scopehttps://learn.microsoft.com/en-us/intune/configmgr/comanage/how-to-switch-workloads (external, new tab)
Learn the Configuration Manager, Pilot Intune and Intune settings. The article also contains change instructions; this guide uses its definitions, not a transition procedure.
Compare co-management and enrollment reportinghttps://learn.microsoft.com/en-us/intune/configmgr/comanage/how-to-monitor (external, new tab)
Distinguish deployment-policy reporting from enrollment evidence and relevant device status.
Checked November 8, 2026. The four-check workflow and blank note are Winhoven’s original investigation synthesis, not a Microsoft diagnostic or transition runbook. Source checks do not establish your tenant’s current state.