The short version
- A network bound to a template becomes that template's “child” and inherits its configuration settings. Changes meant for all bound networks have to be made on the template, not on the individual site.
- Per-site exceptions are supported — but not every setting can be changed on a bound network. Which ones depends on the product line and belongs on the table before the rollout.
- Claiming by Meraki order number has been deprecated. The working method is the order claim key from the product claim emails — and once part of an order has been claimed individually, the order can no longer be claimed as a whole.
- The organisation limits are fixed: 50,000 devices per organisation, 5,000 per network. Growing past that means planning across several organisations.
The appeal of Meraki in a branch estate is easy to tell: one dashboard, one standard, one box someone plugs in on site. That is true — but only if the structure behind it holds. The decisions that carry a rollout, or make it expensive, are all taken before the first site.
What a template is — and what it does to a network
A configuration template is a network whose configuration other networks inherit. Meraki puts it plainly: when a network is bound to a template it becomes a “child” of that template and inherits the template's configuration settings. Whatever was set locally at that site is no longer what the site runs on.
Exceptions: supported, but not everywhere
Sites within a template can have exceptions to the configuration, and devices that need to be treated differently can be bound accordingly. The constraint sitting next to it matters more: not all settings can be changed on a site bound to a template. Which ones depends on the product line — MX, MS, MR and MG each bring their own template rules.
One template per site type, not per site
Templates pay off where a large number of sites share a common network design — retail chains are the textbook case. Meraki states the recommendation unusually plainly: templates should always be a primary consideration during deployments, because they save large amounts of time and avoid many potential errors.
So the practical question is not whether but how many. The answer follows the site types, not the site count: a branch on one circuit, a branch on two, a warehouse, headquarters — that is four types, not forty sites. For building many identical networks Meraki additionally points to cloning: build a “golden configuration network” first, then clone from it.
- Tags are the ordering device, not the network name: Meraki describes tagging as a way to group or identify devices, networks or ports for specific use cases — examples run from location tags like “1stFloor” to mounting tags like “CeilingMount”.
- Settle a naming scheme before the first network. It will appear in every alert, every report and every search afterwards. Renaming later is possible and still a nuisance.
- Name exceptions instead of collecting them. Any deviation nobody wrote down is a surprise at the next template change.
Claiming: the step where the paths diverge
Devices enter the organisation through claiming. Individually that runs on the twelve-digit serial number (cloud ID), in bulk on the order claim key. Important for anyone carrying older instructions in their head or their wiki: claiming by Meraki order number has been deprecated. Meraki points explicitly to the order claim key from the product claim emails.
Where the organisation reaches its limits
| Limit | Value |
|---|---|
| Devices per organisation | 50,000 |
| Devices per network (standalone and combined) | 5,000 |
For the vast majority of branch estates these are not relevant numbers. They become relevant when a group is heading for the ceiling: Meraki then explicitly recommends working with the account team to design a deployment strategy across several organisations. That is an architecture decision, not a configuration question — and it is best taken before the first organisation is full.
The order that works
Cut the site types
Count the shapes, not the sites. One template per type — and for each type, answer which settings may deviate locally.
Settle names and tags
Before the first network, not after the tenth. Both will appear in every alert and every report later on.
Claim orders cleanly
Order claim key for the whole order, before anyone pulls a single device out of it. After that, the bulk route is closed.
Pilot one site and measure it
One type, one real site, one measured result — waves only after that. The pilot is where template mistakes surface cheaply.
Record deviations rather than tolerate them
Every local exception gets a line with a reason. What is not written down shows up at the next template change.
How we run standards, pilot and wave rollout in Meraki projects is described under Cisco Meraki. Which licensing model fits and why that decision belongs at the start is covered in the piece on Meraki licensing models.
Sources
Every evidenced claim in this article can be traced here. The retrieval date shows how fresh the check is.
- Managing Multiple Networks with Configuration Templatesopens in a new tab
Cisco Meraki Documentation · retrieved 26 August 2026
- Using the Organization Inventoryopens in a new tab
Cisco Meraki Documentation · retrieved 26 August 2026
- Building a Scalable Meraki Solutionopens in a new tab
Cisco Meraki Documentation · retrieved 26 August 2026