From recommendation to tenant change

10.1 Operating principle 

Qhub provides recommendations based on Microsoft Graph data and expert rules. It does not make changes in your tenant. Your organization remains responsible for validation, approvals, implementation, and documentation.

10.2 Standard workflow (use for every change) 

Use the same workflow for removals, reassignments, downgrades, and other changes: 

1. Review
   • Start in Dashboard to identify the biggest drivers (inactive, unassigned, downgrade candidates). Then move to Recommendations or the relevant detail pages (Optimized BOM, Spend analysis, Raw data). 
2. Validate
   • Confirm that the recommendation is correct in your context. Typical validations: 
     1. User status: leaver vs. long-term leave vs. seasonal vs. contractor 
     2. Account type: service/test/admin accounts (flagged as “service accounts”) 
     3. Business dependency: critical processes, compliance requirements, VIP users 
     4. Timing: contract constraints (EA/CSP/NCE) and upcoming true-up/renewal windows 
3. Approve
   • Use a simple approval chain: 
     1. IT/SAM owner confirms technical feasibility 
     2. Business owner confirms user impact 
     3. Security/Compliance confirms policy alignment (where applicable) 
     4. Vendor/Procurement confirms contract timing (where applicable) 
4. Implement
   • Execute changes in the appropriate admin tools (e.g., Microsoft 365 Admin Center, Entra, Intune, Azure Portal, Dynamics 365 admin tools). Use staged rollouts for higher-impact changes. 
5. Monitor
   • Confirm impact and detect unintended consequences. Monitor: access issues, helpdesk tickets, security alerts, and license allocation changes. 
6. Document
   • Keep an audit trail: what changed, why, who approved, and when. This is essential for compliance and repeatability. 

10.3 Evidence and data refresh (important for timing) 

• Default refresh cadence: weekly. Refresh frequency can be configured if required. 
• On-demand refresh: can be triggered by Qhub staff (customers cannot trigger refresh themselves). 
• Cost over time: based on historical data points collected over time. When hovering over the chart, users can see the data point and date of collection. 

Practical implication:

When you implement changes in the tenant, expect Qhub to reflect the updated situation after the next refresh (or after an on-demand refresh initiated by Qhub). 

10.4 Example playbooks 

10.4.1 Removing or reassigning inactive accounts

Trigger: Users are considered inactive based on sign-in activity and workload activity signals (Exchange, OneDrive, SharePoint, Skype, Yammer, Teams) over the configured inactivity threshold (customer-configurable, see 4.6). 

Actions: 

• Reassign licenses when you need capacity for new hires or internal moves. 
• Remove/unassign licenses for confirmed leavers or truly inactive accounts. 

Pre-change validation checklist: 

• Confirm inactivity is not due to leave/seasonal patterns 
• Review “service accounts” flags (admin/test accounts are flagged; no accounts are excluded by default) 
• Confirm business owner approval for removal 
• Verify whether the license can be reduced commercially now or only at renewal/true-up (contract timing) 

Post-change monitoring checklist: 

• No new access-related incidents 
• License allocation updated and reflected in Hub after the next refresh 
• Exceptions recorded (and reviewed periodically) 

10.4.2 Downgrading license plans (current engine logic)

Current rule (as implemented today):

A downgrade candidate is a user who: 

• has O365 E3/E5 or M365 E3/E5 assigned, 
• is active within the current inactivity threshold, and 
• has no Office product installations on Windows or Mac.
  In this case, the engine currently calculates downgrade potential as the price difference between the current SKU and an M365 F3 license. 

Important limitation (current behavior): 

• The downgrade target (M365 F3) and conditions are not configurable yet and require improvement. 

Recommended workflow: 

• Treat downgrades as pilot-first changes. 
• Validate with business owners and user groups that F3 is functionally acceptable (F3 has different feature/usage constraints than E3/E5). 
• Consider a staged rollout: 20–50 users → validate impact → expand. 

Pre-change validation checklist: 

• Confirm “no Office installs” matches the user’s real work style (web-only vs desktop apps) 
• Confirm role suitability for F3 (frontline use case vs knowledge worker) 
• Validate any security/compliance requirements that might require E5 features/add-ons 
• Define rollback path (re-upgrade process) 

Post-change monitoring checklist: 

• No productivity blockers reported 
• License mix and cost impact confirmed 
• Document exceptions where E3/E5 must remain 

10.4.3 Azure right-sizing (framework)

If your Hub includes Azure insights, apply the same workflow: 

• Validate with application owners (performance/availability requirements). 
• Start with low-risk actions (dev/test shutdown schedules, orphaned resources). 
• Use staged changes and monitor performance. 
• Align optimization with MACC/MCA commitments (see Section B). 

10.4.4 Dynamics 365 roles and assignments (framework)

• Validate with application owners (roles can be tightly coupled to workflows). 
• Pilot changes, monitor for workflow failures. 
• Keep clear documentation for audit/compliance. 

10.5 Recommended risk and validation guidance 

Qhub does not provide risk indicators today. We recommend applying a simple internal risk approach: 

• Low risk: unassigned licenses; confirmed leavers; clearly inactive accounts (after validation). 
• Medium risk: inactivity with possible exceptions; downgrades with limited feature dependency risk. 
• High risk: privileged/admin accounts; regulated roles; security/compliance-sensitive features; broad SKU mix changes. 

Use pilots and staged rollouts for medium/high risk actions. 

For each recommendation type (e.g., “inactive users”, “downgrade candidates”, “never activated”, “unused features”), we recommend a simple workflow: 

1. Review – Inspect the recommendation list in Qhub and filter by tenant, business unit, or role. 
2. Validate – 
   • Check whether accounts are truly inactive (e.g., long-term leave, service accounts). 
   • Confirm that downgrade candidates do not rely on features that are not visible in usage telemetry (e.g., rare but business-critical use). 
3. Approve – Involve the relevant stakeholders (e.g., line managers, application owners, HR/compliance where required). 
4. Implement – Apply changes in the Microsoft 365 Admin Center, via PowerShell, or through your CSP partner. 
5. Monitor – Use Q Hub to verify impact over time and identify any unintended side effects. 

Start with a small pilot group (e.g., one department or country) before rolling out broad changes across the organization. 

Exceptions & governance 

Not every recommendation should be implemented blindly. Typical exceptions include: 

• VIP users (executives, key account owners) who may require premium features on short notice. 
• Regulated functions (e.g., trading, healthcare, critical infrastructure) where advanced security or compliance features are mandated. 
• Technical or service accounts that appear “inactive” but are required for integrations or automation.

We recommend defining an internal policy that: 

• Lists exception categories. 
• Describes who can approve exceptions. 
• Ensures exceptions are reviewed periodically (e.g., once per year).