Multi-Company & Multi-Plant

A group with three manufacturing entities under one holding company usually runs three different logins, three spreadsheets for spares stock, and a finance team that reconciles asset data by hand every month-end. A single manufacturer with plants in Pune and Baddi has the opposite problem — one legal company, but no clean way to see Line 3 in Baddi as distinct from Line 3 in Pune without renaming everything. AssetAI separates these two problems properly: hard isolation between companies, and a clean location tree inside each one — instead of pretending both are the same problem.

The Boundary Is the Company, Not the Plant

Every record in AssetAI — every asset, work order, and inventory line — carries a company field, and a query scope rewrites every request to stay inside that company automatically. Nobody has to remember to filter by company; it's structural, not a checkbox someone forgets to tick during onboarding. Only a super admin, running the platform console, sees across that boundary.

This matters for a specific kind of buyer: a SaaS operator or a group office running several legally separate companies — each with its own balance sheet, its own auditors — on one AssetAI instance. The company record holds what actually differs between them:

• Plan and billing tier
• Base currency (so a subsidiary billing in USD and one in ₹ don't collide)
• Timezone and locale
• Date format
• Active flag and validity date, for suspending or renewing access

Be clear about what this boundary does not do: it does not separate plants within the same company. A technician in Plant A can see Plant B's assets and work orders if both plants sit inside the same company record. Plant, in AssetAI's model, is a location attribute — not a security wall. If your actual requirement is "the Nashik plant head must never see Baddi's breakdown history," that's not what this module is for, and we'd rather tell you that now than after go-live.

One Company, Many Plants — Modelled as a Tree

Inside a single company, plants are organised as a fixed four-level location hierarchy: plant, area, line, functional location. Each level is auto-coded, so a functional location code tells you exactly where it sits without anyone maintaining a separate numbering scheme in Excel. This is the same structural backbone described on the Asset and Equipment Breakdown Structure page — here, it's what lets multiple physical plants coexist cleanly under one company.

Assets, work orders, and everything else hang off that tree and render as a nested EBS view — so a plant head reviewing Line 2 in Area B sees exactly that subset, structured, not a flat list they have to mentally sort. The depth is fixed at four levels by design. If your plant has an additional layer of complexity you're used to defining yourself — say, a fifth level for sub-lines — that's not configurable here; the hierarchy is opinionated on purpose, and most Indian discrete-manufacturing plants map onto it without needing more.

Users carry a base location, branch, and manager, so every technician and supervisor is anchored somewhere specific in that tree — useful for routing and accountability, even though, as above, it doesn't restrict what they can see across plants.

What Group Reporting Can and Cannot Do

If you're evaluating this for a holding company with four subsidiaries and a CFO who wants one dashboard for all of them — say so upfront, because AssetAI's analytics and dashboards run inside a single company. There is no cross-company or group roll-up view, and super admins themselves are shut out of tenant analytics; the console manages companies and plans, not KPIs.

Data export follows the same rule: every table is filtered to the requester's own company, table by table. That's a deliberate isolation choice, not an oversight — it means a support engineer pulling an export for Company A never touches Company B's rows, even by accident.

If consolidated OEE or downtime trends across companies is a hard requirement, plan for that outside AssetAI — export per company and roll up in your own BI layer, at least for now. If your real need is comparing plants within one company, that's native, because they already share one dashboard and one location tree — no roll-up required.

Support Access Without Losing Control

Group deployments usually need a support path — someone from the platform side has to help a tenant without asking for their password. AssetAI handles this with impersonation: a super admin opens a tenant as its oldest active Company Admin, with a single click to return to the console.

Two details make this safe to run in production rather than just convenient:

• Both entering and leaving impersonation are written to the activity log, with the target admin's email attached — so there's a durable record of who looked at what, and when.
• Leaving impersonation verifies the underlying session still belongs to a genuine super admin before handing control back, rather than trusting a stale token.
• If a company has no active Company Admin to impersonate as, the attempt fails cleanly with a message — it doesn't silently log in as nobody or throw a raw error.

Deactivated users can't log in at all, which closes an obvious gap: an offboarded employee's credentials stop working immediately, not whenever someone remembers to revoke access manually.

Who This Setup Actually Fits

This module is built for two fairly different buyers, and it's worth naming both so you can place yourself correctly.

• A group or SaaS operator running several legally separate companies on shared infrastructure, needing real company-level separation plus a supportable impersonation path for their own admin team.
• A single manufacturer with multiple plants — think a component maker with units in Chennai and Rudrapur — who wants them modelled as one location hierarchy under one company, sharing one dashboard, one asset registry, one set of work order data.

It is a poor fit if you need consolidated KPIs across legally separate companies without exporting data manually, or if your compliance posture demands that Plant A staff can never see Plant B's maintenance records — that would require plant-level isolation, which isn't how this is built. For the broader question of what a maintenance system should even cover before you get to tenancy, the what is a CMMS page is a reasonable starting point, and the OEE explainer is useful once you're comparing lines within a single plant. For standards context on how multi-site quality and maintenance programs are typically audited, ISO's standards library is a good outside reference.

If your structure matches — one company, several plants, or several companies needing clean separation with a support path — the pricing page has the plan tiers, and booking a demo is the fastest way to check the location hierarchy against your actual plant layout before you commit to it.

Planning the Location Tree Before You Go Live

The most common rollout mistake isn't technical — it's naming. Teams start entering "Line 3 — Extrusion — B Shift" into a level meant to just be "Line," and six months later nobody's filters work cleanly. Because AssetAI fixes the hierarchy at four levels — plant, area, line, functional location, each auto-coded — the discipline has to come from your side, at the start, not from the software enforcing it later. Before go-live, walk the actual plant floor with your engineering and stores teams and agree on what an "area" means at your site versus what belongs one level down as a "line." Get this settled once, on paper, and the nested EBS view stays usable for years. Get it wrong, and you're renaming functional locations while work orders are already open against them.

Rollout Roles: Who Sees What, and Who Fixes What

Every user carries a base location, branch and manager — so a new hire in Baddi is anchored there from day one, not floating in an unassigned bucket. Decide early who your Company Admins are, because impersonation depends on it: support can only step into a tenant as its oldest active Company Admin, and if that seat is empty or deactivated, impersonation fails outright with a clear message rather than defaulting to someone unintended. That's a good discipline forcer — it means at least one real, active admin per company is a structural requirement, not a nice-to-have.

• Assign at least one Company Admin who won't be the first person offboarded
• Keep base location and manager fields current as staff move between plants
• Remember deactivated users are blocked at login, not just hidden from lists

What to Watch After Go-Live

Once live, the two things worth checking monthly are the activity log and your export routine. Impersonation entries and exits are both logged with the target admin's email, so a quick scan tells you whether support access is being used appropriately. Data export is filtered strictly per company, which is what makes month-end reconciliation for a multi-entity group workable without one finance sheet accidentally pulling another subsidiary's numbers.

If your group also tracks OEE or uptime targets across entities, plan for that reporting outside AssetAI — dashboards here run inside one company by design, closed even to super admins, so there's no roll-up screen to wait for.

Where This Setup Won't Help You

Be honest about two situations before you commit:

• If plant heads need to be stopped from seeing another plant's breakdowns or spares stock — say, for contractual or data-sensitivity reasons — this isn't that tool. Plant is a data attribute here, not a security wall.
• If your board wants one consolidated KPI view across group companies, you'll be exporting and combining manually, not clicking a toggle.

Everything else — ISO 55000-aligned asset structuring, plant-wise maintenance planning, contract labour rosters tied to a base location — fits comfortably. Check /pricing once you've mapped your plants, or book a walkthrough with your actual location list in hand rather than a hypothetical one.