Setup guide · from scratch
Configure actions for noncompliance with a grace period
Stops surprise Conditional Access lockouts. Give the mandatory 'Mark device noncompliant' action a grace period and add a 'send email to end user' remediation notice before the block bites.
≈ 15 min
Across every platform · step 2 of 2 · ≈ 15 min‹ Previous
Do these first — this guide assumes you already have:
The Decolla way — skip the clicks.
Every step below can be done by hand. Or connect your Microsoft tenant to Decolla once, and Decolla performs this for you over Microsoft Graph in your own tenant — then hands back a verified result you can see and roll back per item. It also puts the fundamentals this step depends on in place — the target group, the licence allocation — so a build is never blocked half-way by a missing dependency.
⏱ By hand: about 15 min of clicking, every build. The Decolla way: part of one tenant connect, then automatic.
Before you start
- The exact group you will target, already created in Entra - and a decision on DEVICE group or user group before you start, never both.
- An agreed grace-period length (e.g. 3 days), signed off by whoever owns the security posture - it delays enforcement, so it is a policy call, not a technical one.
- An Intune sign-in with rights to edit Compliance policies and the notification message templates.
- The wording for the end-user email, or agreement to use a default template - the message is created inline during the flow.
The steps
- Go to Devices > Compliance and sign in as the Example Company admin.
- Open the policy (or Create policy > pick platform > Create) and set your rules on…
- On 'Actions for noncompliance' change the mandatory 'Mark device noncompliant'…
- Click '+ Add' > 'Send email to end user'; Select a message template > Create a…
- (Optional) Add 'Remotely lock the noncompliant device' with its own schedule.
- On Assignments add the correct DEVICE group (or user group — never both for the…
- Separately check Devices > Compliance > Compliance policy settings > 'Compliance…
0 of 7 done
Step 1. Go to Devices > Compliance and sign in as the Example Company admin.
Screenshot: Compliance policies list (captured during a live customer build — coming to this page)
Why: Compliance policies are what Conditional Access reads to decide whether a device may reach mail and apps - this blade is the source of that verdict.
Don’t: Do NOT do this work in Devices > Configuration - configuration profiles push settings, compliance policies set the pass/fail that gates access.
If this step errors: Intune 'Available' apps not showing in Company Portal
Step 2. Open the policy (or Create policy > pick platform > Create) and set your rules on the Compliance settings step.
Screenshot: Compliance settings step (captured during a live customer build — coming to this page)
Why: The rules you set here are the actual pass/fail tests; the grace period only matters once a device fails one of them.
Watch for: Compliance policies are per-platform - a rule set for Windows does nothing for the Android or iOS fleet, so confirm you are editing the right platform's policy.
If this step errors: Intune policies taking 8 hours? Check WNS first
Step 3. On 'Actions for noncompliance' change the mandatory 'Mark device noncompliant' Schedule from 0 to a grace value (e.g. 3 days).
Screenshot: Day-count changed from 0 to the grace value (captured during a live customer build — coming to this page)
Why: 'Mark device noncompliant' is the action that trips Conditional Access; a grace value gives the user days to self-remediate before access is cut, instead of the instant block a 0 produces.
Watch for: The default is 0 days, which means block immediately - it is easy to leave it untouched and never realise you have built an instant-lockout policy.
Don’t: Do NOT pad the grace period to feel 'safe' - every extra day here is a day a genuinely noncompliant device keeps its access.
Step 4. Click '+ Add' > 'Send email to end user'; Select a message template > Create a remediation message; set its Schedule to 1 day.
Screenshot: Email notification message-template editor (captured during a live customer build — coming to this page)
Why: The email turns a silent block into a warning - the user learns why access is about to go and what to fix, ideally before the grace period ends.
Watch for: Set the email Schedule earlier than the 'Mark noncompliant' grace value (e.g. 1 day against 3) - an email that lands the same day as the block warns nobody.
Don’t: Do NOT skip saving the message template - without a saved message the 'Send email' action has nothing to send.
Step 5. (Optional) Add 'Remotely lock the noncompliant device' with its own schedule.
Screenshot: Remote lock action row (captured during a live customer build — coming to this page)
Why: Remote lock is a harder escalation for high-risk fleets - it locks the handset itself rather than only cutting Conditional Access.
Don’t: Do NOT apply remote lock to personally-owned devices lightly - locking someone's own phone over a compliance drift is a support call and a trust problem.
Step 6. On Assignments add the correct DEVICE group (or user group — never both for the same setting); Review + Create.
Screenshot: Assignments step (captured during a live customer build — coming to this page)
Why: Assignment is what makes the policy live; an unassigned compliance policy evaluates nothing and silently protects nothing.
Watch for: Targeting a device group and a user group at the same devices creates evaluation ambiguity - pick one axis and stay on it.
Don’t: Do NOT assign to All devices or All users on a first rollout - pilot on a small group so a mistuned grace period cannot lock out the whole tenant.
Step 7. Separately check Devices > Compliance > Compliance policy settings > 'Compliance status validity period' (default 30 days) so an un-checked-in device isn't auto-flagged.
Screenshot: Compliance policy settings showing the validity period (captured during a live customer build — coming to this page)
Why: This period decides how long a device's last compliant verdict is trusted before Intune demands a fresh check-in; set it too short and dormant-but-fine devices flip to noncompliant.
Watch for: It is a tenant-wide setting tucked away from the policy itself - people tune the grace period and never touch this, then wonder why weekend devices go noncompliant.
On a schedule: This sets a recurring re-validation: every device must check in within the validity period or lose its compliant status - keep it aligned with how often the fleet actually syncs, not shorter.
Put these on a schedule
| Step | Recurring action to diarise |
|---|---|
| Step 7 | This sets a recurring re-validation: every device must check in within the validity period or lose its compliant status - keep it aligned with how often the fleet actually syncs, not shorter. |
If it goes wrong
The failures people actually hit on this process, each with the diagnosis and fix:
- Intune policies taking 8 hours? Check WNS first — Intune delivers policy changes in minutes via WNS; the 8-hour sync is only a safety net. If WNS is blocked at the firewall, here's how to fix it.
- Intune 'Available' apps not showing in Company Portal — Intune 'Available' app assignments to device groups are silently ignored for almost every app type. The full intent-by-target support table and the fix.
See it on a real device.
Decolla is in private build — early-access members see a build defined, deployed and rolled back first.
Get early access