Map multiple Datto RMM sites to a single REWST organizations to unify automation and reporting across distributed company locations.
K
Krypton green Peacock
In environments where a single company operates across multiple physical or logical locations, Datto RMM often represents each location as a separate "Site" for operational clarity and device segmentation. However, in Rewst—specifically within the Rewst —organizations are typically modeled as unified entities.
To bridge this structural mismatch, a mapping mechanism is required that links multiple Datto RMM Sites to a single Organization in REWST. This mapping enables Rewst workflows to treat all related sites as part of one cohesive business entity, allowing for centralized automation, reporting, and policy enforcement across all sites associated with that company.
This can be implemented using a configuration object or lookup table in Rewst that associates each Datto RMM Site ID with a corresponding Roost Organization ID. Automations can then reference this mapping to ensure actions are executed in the correct organizational context.
Use Case:
Scenario: A managed service provider (MSP) supports a client, “Acme Corp,” which has three regional offices—each configured as a separate site in Datto RMM: Acme-East, Acme-West, and Acme-Central.
Problem: When a Rewst automation is triggered (e.g., a patch compliance check or alert remediation), it needs to understand that all three sites belong to the same client organization to apply consistent business logic and reporting.
Solution: A mapping is created in Rewst that links all three Datto RMM Site IDs to the single “Acme Corp” organization in Roost. Now, when an automation runs, it can:
Aggregate data across all sites for unified reporting.
Apply organization-wide policies (e.g., alert thresholds, escalation paths).
Route tickets or notifications to the correct stakeholders at the organizational level.
Log In
N
Numerous Stoat
We def have companies which have location splits in RMM (although as part of moving to Rewst we ended up redesigning our RMM structure instead and sorting them with groups instead of sites.
K
Krypton green Peacock
As I dive deeper into the mystical realms of REWST organization structures, I’ve had a revelation—nay, a vision! What if we added a third tier to our hierarchy? Picture this:
Parent Organization – The mighty MSP overlord, the all-seeing eye, the supreme ruler of the REWSTiverse.
Child Organization – The client, loyal subject of the Parent, but with a rebellious streak and a penchant for independence.
Grandchild Organization – The customer sites. These are the wildcards. The rogues. The Han Solos of the REWST galaxy. They follow the rules... unless they don’t.
Why a Third Tier?
Because reality is messy. Tools like RMM, Auvik, and other site-specific applications don’t always play nice when everything is lumped into one big happy family. Sometimes, you need to say, “Hey, this config is just for Site A, not the whole dang client!”
With a Grandchild tier, we can:
Assign tools and integrations at the site level.
Keep configurations clean and scoped.
Avoid the dreaded “Why is this alert firing for every site?” scenario.
The Power Dynamic
Let’s talk governance, because every good empire needs rules:
Parent Org: The Emperor. Sets the laws of the land. All defaults, flows, and variables cascade from here.
Child Org: The Governor. Can override the Emperor’s laws with local edicts (a.k.a. variables and flows).
Grandchild Org: The Rebel Base. They do what they want. If they define their own variables or flows, they take precedence. If not, they fall back to the Child, and then the Parent.
It’s like inheritance, but with more drama.
Let’s build a third-tier org structure in REWST: Parent → Child → Grandchild. It’ll make tool integration cleaner, governance more flexible, and give us the power to manage chaos like pros.