Datto RMM new configuration applies in test group but not production users

Issue Summary

This article covers a Datto RMM issue within RMM / PSA / Automation where Datto RMM new configuration applies in test group but not production users. Use the path below to confirm scope, separate user-facing symptoms from administrative causes, and move from Tier I checks into deeper remediation without introducing broad risk.

Symptoms and Scope

• The reported problem matches the article title: Datto RMM new configuration applies in test group but not production users.
• At least one reproducible user, device, tenant, message, or workflow can be compared with a known-good example.
• The current failure can be tied to a recent change, policy, update, sync event, or integration dependency.

Tier I: Basic Checks

1. Confirm business impact, affected users, and whether the issue is isolated, role-based, tenant-wide, or device-specific.
2. Capture exact errors, timestamps, and reproduction steps before changing configuration.
3. Validate the simplest path first: retry with a clean session, known-good user, or alternate client to narrow the fault domain.
4. Check whether the failure began after a change in policy, licensing, credentials, sync, routing, or update state.

Tier II: Admin Investigation

1. Review product-specific logs, policy assignments, connector or sync health, and recent administrative changes tied to Datto RMM.
2. Compare the failing object against a working example so you isolate whether the break is user, device, group, tenant, or service side.
3. Apply the least disruptive administrative fix first and confirm whether the result survives reauthentication, restart, or refresh.
4. Document the exact policy path, integration state, or dependency that explained the failure.

Tier III: Advanced Remediation

1. Move to advanced remediation only after lower-tier checks are documented and reversible.
2. If integrations are involved, validate the full chain across identity, routing, API, synchronization, and any downstream service dependencies.
3. Rebuild or re-authorize connectors, profiles, sync relationships, certificates, or service components only when evidence points there.
4. Validate the final state from the end-user view and the administrative view so the fix is operationally real, not just cosmetically improved.

Escalation Guidance

• Escalate when the issue affects multiple users, a critical business workflow, or a security-sensitive control that cannot be broadly bypassed.
• Include exact symptoms, timestamps, screenshots, logs, message identifiers, and the Tier I / II / III work already completed.
• State clearly whether the blocker is policy, sync, identity, licensing, routing, integration, or platform health so the next technician can continue cleanly.

Prevention and Documentation

• Document the root cause, stable fix, and any exception or special configuration added so future reviews can keep scope tight.
• Update runbooks, onboarding steps, monitoring, or change-control notes if the failure followed a repeatable pattern.
• Where possible, add validation or alerting that would catch the same issue before users discover it first.