Concepts

Templates, profiles, and tenants

The three building blocks that decide what runs on a device and for which client — and when you actually need a tenant.

4 min readUpdated Jul 20, 2026

The short version

Three things decide what happens when you provision a device:

  • Steps are the individual actions — install Windows, register with Autopilot, set the language.
  • Templates bundle steps into a reusable, ordered recipe.
  • Profiles take a template, tailor it for a specific client, and are what a technician actually picks when generating a code.

A tenant is a separate idea: it represents one client's Microsoft environment. You only need one connected when a profile does something inside Microsoft — most commonly Autopilot. More on that below.

Steps

A step is one unit of work — "install Windows 11", "register the device with Autopilot", "set keyboard to Belgian", "enable BitLocker". Each step comes from StageReady's built-in catalogue; you don't script them.

Some steps run on the device (via the USB), and some run on the StageReady backend (like registering a device with Microsoft). You don't have to worry about which is which — you just arrange them.

Templates

A template is an ordered list of steps you can reuse across many clients. Instead of rebuilding the same setup every time, you define it once.

There are two kinds:

  • Base template — the spine of a build (e.g. "Standard Windows 11 laptop"). A profile starts from exactly one base template.
  • Addon template — an extra set of steps you can layer on top (e.g. "HR tools", "Dell BIOS settings", "SAP"). A profile can include several addons.

Templates have a lifecycle: Draft → Published → Archived. Once a version is published it's frozen, so a job that's already running is never changed underneath you. Editing a template later creates a new revision; existing jobs keep the version they started with.

Profiles

A profile is what you actually assign to a client and what a technician selects at code-generation time. It takes a base template and makes it real for a specific situation by combining:

  • a base template (and optionally one or more addons),
  • variable values — admin-set settings like Language = Dutch,
  • step overrides — small per-step tweaks,
  • a parameter schema — the fields a technician fills in per device.

Profiles can also inherit from a parent profile and store only the differences. So you might have a company-wide base profile, and per-client child profiles that only change the language and add one addon — no copy-paste.

Template vs profile in one line: a template is the reusable recipe; a profile is that recipe tailored for a client and ready to run.

Variables vs parameters

Both fill in the blanks in a setup, but at different times:

  • Variables are set by an admin ahead of time and apply to everything that uses them — e.g. {{Language}}.
  • Parameters are filled in by the technician when they generate the code, per device — e.g. {{ComputerPrefix}} or {{AssetTag}}.

Tenants

A tenant is one client organization's Microsoft 365 / Entra ID environment. An MSP manages many. In StageReady, tenants do two jobs:

  1. Microsoft access — when a step needs to act inside a client's Microsoft environment (register a device with Autopilot, assign it in Intune, add it to an Entra group), StageReady uses that tenant's connection. See CIPP and delegated access for how those connections work.
  2. Scoping — technicians are assigned to the tenants they're allowed to work with, and profiles are made available per tenant.

Do you actually need a tenant?

Only if a profile does something inside Microsoft.

  • Doing Autopilot (or Intune / Entra steps)? Then yes — you need that client's tenant connected with credentials, because StageReady has to talk to their Microsoft environment to register the device.
  • Just installing Windows and applying local settings — language, keyboard, region, timezone, BitLocker — with no Microsoft enrolment? Then no Microsoft access is needed. You can run against a single placeholder/sample tenant without connecting any credentials at all.

In other words: tenants are about Microsoft integration and access, not about provisioning itself. For now the main reason to add real client tenants is Autopilot and delegated access. If that's not part of your flow yet, one sample tenant is enough to get going, and you can connect real client tenants later when you start enrolling devices.

Where to go next