The Operational Tax of Many Tenants

Once an MSP crosses about fifteen ServiceNow tenants, the operational tax shifts from per-customer to per-fleet. Each tenant has its own release line, its own patch level, its own custom apps, its own SLAs, and its own change calendar. The team that operates them needs to know which tenant is on which release without opening a different browser tab for each.

SnowCoder is built around the assumption that an MSP workspace will hold dozens of connected tenants. The MSP Agents, Yeti AI Chat, the Yeti Build Agent, and the MCP integration all operate against the connected estate as a whole, not against a single instance at a time. This article describes how that works in practice.

The Tenant Connection Model

Each ServiceNow tenant is connected to a SnowCoder workspace via OAuth. The connection is scoped to read-only by default. Write operations require an explicit elevation. The connection record holds the instance URL, the OAuth tokens, a tenant label, a contract tier (Bronze, Silver, Gold, Platinum), and a tag set. The tag set is how MSPs slice their estate for scheduled runs: by region, by industry, by SDM owner, by contract anniversary.

The contract tier matters because the agents read it. SLA Guardian thresholds, Patch Manager prioritisation, and Instance Audit Agent default scopes all key off the tier. A Platinum customer triggers tighter pre-breach thresholds. A Bronze customer gets longer change windows.

Isolation between tenants is enforced at the workspace level. Data harvested from tenant A is never visible inside a Yeti AI Chat conversation pointed at tenant B. The agents share their knowledge base (the 100,000-plus vector ServiceNow corpus and 17,000-plus code examples) but never share tenant data.

What Runs Per-Tenant, What Runs Cross-Tenant

The MSP Agents fall into two buckets. Six scheduled agents and two on-demand agents.

The six scheduled agents run automatically on a per-tenant cadence but report cross-tenant.

Instance Health Monitor: Runs daily, reports cross-tenant health.
SLA Guardian: Runs hourly, reports per-tenant with cross-tenant heat map.
Incident Manager: Runs on a defined cadence, surfaces P1/P2 trends per tenant and across the fleet.
License Optimizer: Runs weekly, identifies idle fulfillers and role-bloat per tenant.
Patch Manager: Runs monthly, produces the estate-wide roadmap.
AI Readiness Advisor: Runs monthly, scores each tenant's readiness for Now Assist and SnowCoder MCP adoption.

The two on-demand agents are triggered when an architect or service manager needs them.

Instance Audit Agent: 500-plus checkpoints, used during sales pursuits and quarterly customer reviews.
Upgrade Readiness Agent: Triggered before a release upgrade conversation.

The split matters operationally. The scheduled agents fill a dashboard the SDM looks at every morning. The on-demand agents fill specific commercial moments.

Querying Across the Estate with Yeti AI Chat

Yeti AI Chat sits on top of the connected estate. A service manager can ask questions in plain English that fan out to multiple tenants. "How many P1 incidents are open across all Platinum customers right now?" is a single question that compiles a GlideAggregate across the matching tenants.

Behind the scenes that translates into something like the pattern below, executed per tenant and then rolled up.

var ga = new GlideAggregate('incident');
ga.addQuery('priority', 1);
ga.addQuery('active', true);
ga.addAggregate('COUNT');
ga.query();

if (ga.next()) {
    var count = ga.getAggregate('COUNT');
    gs.info('Tenant ' + tenantLabel + ': ' + count + ' P1 active');
}

// SnowCoder fans this out across every connected
// tenant tagged "platinum", then aggregates the results
// into the answer the service manager sees.

Isolation is preserved. The service manager never sees raw records from a tenant they do not have access to. The cross-tenant view is an aggregate by design.

Per-Tenant Runbooks

The risk with operating dozens of tenants from a shared workspace is that local context gets flattened. Customer A's Saturday change window is not customer B's. Customer C uses a non-standard SLA schedule because their support contract is global. Customer D has a custom escalation rule that should not be touched.

SnowCoder stores per-tenant runbooks alongside the connection record. The runbook is a markdown document the MSP team maintains. Yeti AI Chat reads it before answering tenant-scoped questions, and the scheduled agents read it before generating tenant-scoped recommendations. A typical runbook fragment looks like this.

# Tenant runbook: globex-prod

Contract tier: Gold
Region: APAC
Primary SDM: [email protected]
Change windows:
  - Saturday 22:00-02:00 AEST (preferred)
  - Sunday 03:00-05:00 AEST (fallback)

Custom rules to respect:
  - Do not touch u_escalation_matrix without architect review.
  - SLA schedule "Globex APAC 24x7" is custom; do not auto-suggest
    the default 8x5 schedule.

Notes:
  - On Now Assist roadmap for FY26. Mention in monthly readout.

The runbook is the mechanism that keeps cross-tenant tooling from issuing dumb cross-tenant recommendations.

The Per-Tenant ACL Pattern

On the ServiceNow side, the integration user that SnowCoder authenticates as in each tenant should be locked down with a focused ACL pattern. The minimum permissions are read on the tables the agents inspect, plus the ability to write only when explicit write operations are approved. A typical pattern is the one below.

// Role: snowcoder_integration (read)
// Grants:
//   - read on incident, problem, change_request, task_sla
//   - read on sys_upgrade_history_log, sys_plugin, sys_store_app
//   - read on sys_script, sys_script_client, sys_script_include
//   - read on cmdb_ci and child tables
// Does NOT grant write on any table by default.

// Role: snowcoder_integration_writer (elevated)
// Granted only when an architect approves a write operation.
// Time-bounded via a system property:
gs.getProperty('snowcoder.write.window.minutes', '30');

The pattern keeps the integration user safe by default. Writes are gated by a time-boxed elevation and logged so the audit trail is intact.

Why MSPs Standardise on SnowCoder

The MSPs running fifty-plus tenants in SnowCoder do so for the same reason: the per-tenant work scales sublinearly. Adding the fifty-first tenant does not cost as much as the fiftieth did. The scheduled agents pick up the new tenant automatically. The runbook takes an hour to write. The estate-wide views absorb the new instance. The marginal cost of growth gets cheaper as the estate gets bigger, which is the opposite of what happens with spreadsheets and tab-switching.

That economic shape is why MSPs are the use case SnowCoder was tuned for from day one.

Multi-Tenant ServiceNow with SnowCoder: How MSPs Manage 50+ Instances