> ## Documentation Index > Fetch the complete documentation index at: https://docs.byblend.com/llms.txt > Use this file to discover all available pages before exploring further. # Can Blend support multiple brands, franchises, and locations? > Yes. Blend models a brand above its clinics, and locations beneath them, so a franchisor with many owners, an owner with many sites, and a single independent clinic all work in the same system. Blend is built for organizations that aren't a single clinic. The data model has three tiers — **brand**, **customer**, and **location** — and you use as many of them as your structure needs. A franchisor with dozens of independent owners, an owner running several sites, and a standalone practice are all first-class shapes, not workarounds. Everything scopes to the tier it belongs to: products can be shared across a brand or overridden per clinic, users can be granted brand-wide access or held to one clinic, and reporting rolls up or drills down accordingly. ## The three tiers The shared identity above a group of clinics. Owns brand-level products and gives brand-wide users and reporting a place to sit. An individual clinic or franchise owner — in Blend, "customer" and "clinic" mean the same thing. The account that owns patients, prescriptions, and orders, and the tier the API operates at. A physical site under a clinic, with its own business name, address, and phone. Used to route inbound prescriptions and to filter reporting. ## Shared catalog, local overrides Products can be defined once at the brand level and shared by every clinic underneath, while any individual clinic can override the parts that differ for them — display name, SKU, product code, pricing. An override is a variation on the **same** product, not a separate one. That's what makes brand-wide reporting meaningful: thirty clinics selling the same preparation under thirty local names still roll up as one product. Which products a clinic sees is configurable. A clinic can inherit the full catalog and have specific items removed, or start from nothing and have items added deliberately — and either way it keeps its own custom formulations. ## Access across clinics Users can be scoped to one clinic, or granted **brand-level** access spanning every clinic beneath the brand. A brand user can act for one clinic or all of them, and sees orders, patients, prescribers, products, stuck orders, patient messaging, and metrics across the group. They can create orders, edit patient and prescriber data, respond to patients, and work stuck orders — the same actions, over a wider scope. ## Reporting that rolls up The [Metrics report](/guides/metrics-report) scopes to a single clinic, to an entire brand, or to a single location within a clinic. A franchisor can compare turnaround across every owner in the group; an owner can compare their own sites; a single clinic sees only itself. ## Routing prescriptions to the right place Each location carries its own business name, which is what lets Blend attribute an inbound prescription to the right site — important when several locations under one clinic prescribe under distinct practice names. ## What this means for your integration The API operates at the **customer** level. Your credentials are scoped to a clinic, and patients, prescriptions, and orders belong to that clinic. If you integrate on behalf of several clinics in a brand, you'll typically hold credentials per clinic — which also keeps each clinic's data cleanly separated. Talk to your Blend contact about your structure before onboarding. Whether prescribers, patients, and products should be shared across a brand or kept separate per clinic is a decision worth making deliberately at setup, and it's much easier to get right up front than to reorganize later. Brand roll-ups and location filters SKUs and product codes per clinic Credentials are scoped per clinic Prescribers associate across accounts by NPI