--- title: "Manage multiple 3D printers across locations" slug: manage-multiple-3d-printers description: Manage multiple 3D printers across sites with clear ownership, one queue policy, supported mixed-brand visibility, maintenance, access rules, and escalation. target_keyword: manage multiple 3d printers secondary_keywords: - multiple 3d printer management - manage 3d printers across locations - multi location 3d printer management - remote 3d printer fleet management audience: enterprise category: guides tags: - enterprise - multi-location - fleet-management - print-queue - operations schema: TechArticle last_modified: 2026-09-02 published: 2026-09-02 author: albert readtime: 12 og_image: https://cdn.simplyprint.io/i/static/og/enterprise.jpg og_image_alt: SimplyPrint Enterprise overview for governing connected 3D printer fleets, users, and sites card_image: https://cdn.simplyprint.io/i/landing/enterprise/hero/organisation.webp card_image_alt: SimplyPrint organisation settings for user groups, permissions, security, quotas, registration, and single sign-on card_image_no_shadow: true cta_inline: text: Explore multi-location 3D printer management url: /enterprise cta_final: text: Bring your 3D printer locations into one governed workflow url: /enterprise#book-a-demo related_features: - OrganisationManagementFarmEnterpriseFeatureController - PrintQueueFeatureController - MaintenanceFeatureController related_articles: - 3d-printing-workflow-software - 3d-print-farm-maintenance-checklist - how-to-start-a-3d-print-farm faq: - q: What is the best way to manage multiple 3D printers? a: | Give every printer a named site and local owner, put supported connected FDM/FFF printers in one inventory, route work through a shared queue, and define who can submit, approve, start, cancel and administer jobs. Keep maintenance state, escalation and usage records beside the printer. Add automation only after ownership and exception rules are clear. - q: Can one SimplyPrint account manage printers in different buildings or countries? a: | Yes. Enterprise organisations can coordinate locations under one agreement while keeping local account boundaries and administrators. Within an account, printers can be grouped by facility, department or use. Exact company and data-hosting topology should be scoped with SimplyPrint for the organisation's identity, billing and residency needs. - q: Can SimplyPrint control resin, metal, or powder-bed printers? a: | Not as connected printers. SimplyPrint's connected control is for supported FDM/FFF hardware and connection methods. Other equipment can be represented as virtual machines for planning or records, but the platform does not gain live status, camera control or machine commands for unsupported processes. - q: How should queues work across multiple locations? a: | Start with local queues and explicit eligibility rules. Route a job only to printers that match its approved profile, material and operational requirements. Make cross-site transfer an operator decision when shipping, data access, material availability or local responsibility changes. A single global queue is not automatically the simplest policy. - q: Does multi-location management require self-hosting? a: | No. The managed cloud is the standard deployment and supports remote access to connected printers. Self-hosting can be scoped for select Enterprise customers by technical and commercial agreement when an infrastructure policy requires it; it is not automatically air-gapped or a certification shortcut. tldr: | To manage multiple 3D printers, standardize the operating model before the dashboard: assign each printer to a location and owner, define submission and approval rights, route work through eligible supported FDM/FFF printers, take maintenance machines out of automated dispatch, control manual starts, and keep local escalation inside a centrally visible workflow. expertise_note: | This guide is based on SimplyPrint's implemented Enterprise locations, organisation controls, SSO and group mapping, mixed supported FDM/FFF fleet view, print-queue matching, maintenance mode, statistics, REST API and webhooks. It does not infer deployment sizes or outcomes from unnamed users. --- To manage multiple 3D printers across locations, start with ownership and routing, not a wall of camera feeds. Every printer needs a site, an accountable local owner, an approved connection and profile, a rule for which jobs it may receive, and a clear state when it is unavailable. Every user needs a reason to submit, approve, dispatch or administer work. The operating pattern is: 1. inventory supported connected FDM/FFF printers by site and responsibility; 2. standardize names, profiles, material and eligibility data; 3. separate requester, operator, technician and administrator rights; 4. route jobs through queues with explicit local or cross-site policy; 5. exclude maintenance and out-of-order printers from automated dispatch and control manual starts; 6. keep central reporting while local teams own physical interventions; 7. integrate with surrounding systems only at deliberate handoff points. That is what turns many remote printers into one manageable service without pretending every building or machine is identical. ## How to manage multiple 3D printers: map the fleet first Create a simple inventory before migrating software. One row per printer is enough if the fields make differences visible: | Field | Why it matters | | :--- | :--- | | Location and time zone | Identifies the team that can physically respond and when it is available | | Department or service | Separates an engineering lab, classroom, maintenance shop and production-support cell | | Local owner and backup | Gives alerts, failures and access requests a human destination | | Printer model and connection | Determines whether connected control is supported | | Nozzle, build surface and approved materials | Defines which queued jobs are eligible | | Approved slicer profile | Prevents each site from quietly creating a different process | | Camera and privacy policy | Defines whether a feed may be shown and to whom | | Maintenance status | Signals that automated dispatch must exclude the machine and manual starts need control | | Network and identity boundary | Shows when a site needs different access or deployment treatment | Check the exact model and connection on the [SimplyPrint compatibility list](/compatibility). Connected management applies to supported FDM/FFF printers. An unsupported resin, powder or metal machine can be recorded as a virtual machine in some workflows, but it does not become remotely controllable and does not provide live telemetry merely because it appears in an inventory. The inventory also reveals whether one account topology fits. Enterprise organisations can create distinct locations under one parent organisation, with local data and settings plus central switching, shared SSO, and pooled or separate commercial setups. Separate independent accounts may still be appropriate for unrelated legal entities or incompatible residency and identity requirements. Decide that boundary with IT and the service owner before importing hundreds of users. That is the core of multiple 3D printer management across sites: manage 3D printers across locations through a common information model, while keeping physical response and printer-specific procedures local. Multi location 3D printer management and remote 3D printer fleet management are operating arrangements, not merely remote access to several browser tabs. ## Choose central rules and local ownership deliberately Multi-location operations work when central and local responsibilities are explicit. **Central platform owners** usually define: - identity provider and account access rules; - baseline user groups and permissions; - approved printer and slicer profiles; - naming and tagging conventions; - required queue states and reporting fields; - API, webhook and data-retention ownership; - escalation standards and change control. **Local operators** usually own: - physical setup and material loading; - first-line submission review and printer assignment; - first-layer or in-person checks required by local policy; - clearing completed work; - reporting faults and starting maintenance jobs; - return-to-service verification; - site opening hours and physical safety procedures. Central visibility does not remove the need for someone near the printer. Remote software can show status and, on supported connections, provide controls and camera access. It cannot remove a failed part from a bed, investigate an unexpected smell, confirm a workspace is clear, or decide that local conditions are safe. :::image src="https://cdn.simplyprint.io/library/web/auto/desktop/panel/settings/organization-overview-page-landing.png" alt="SimplyPrint organisation settings overview with access, permissions, quotas, registration, single sign-on, and feature-control sections" caption="Keep organisation-wide access and policy in one place while local operators remain responsible for physical printer work."::: ## Give users roles that match decisions Avoid giving everyone either no access or administrator access. Build roles around decisions: - **Requester:** upload or select a file, provide required job data, see their submission and respond to review comments. - **Reviewer or approver:** confirm the job has the required profile, material, priority and authorization before it becomes dispatchable. - **Operator:** assign or start eligible jobs, respond to alerts and manage the local queue. - **Technician:** report and resolve problems, work maintenance jobs and record parts or test results. - **Site administrator:** manage local printers, groups and users within the approved boundary. - **Organisation administrator:** own identity, permissions, integrations and cross-location policy. SimplyPrint organisation management supports user groups and granular permissions. Enterprise identity can use SAML 2.0 or OpenID Connect, with supported provisioning and identity-provider group mapping. Design the group map so a person's existing department, class or operator assignment gives them the intended role; do not rely on someone remembering to edit users individually after every staff change. Use temporary access for contractors or visiting users when access should end on a known date. Keep administrator groups small, require the organisation's approved authentication controls, and review audit evidence according to your own security policy. The [SSO feature](/features/sso) and [organisation management page](/features/organisation-management/farm-enterprise) describe the implemented controls. A location or internal network should not be the only reason an identity is trusted. [NIST's Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/800/207/final) is a useful primary reference for the broader access principle; the organisation still decides how that principle maps to its identity provider, devices and printer operations. ## Build the queue around eligibility, not proximity alone A queue answers two separate questions: 1. Which work should run next? 2. Which printers are allowed and able to run it? Do not collapse those into "send to the first idle printer." A useful queue item carries the information an operator or matching rule needs: approved file or profile, quantity, material, colour when relevant, nozzle or equipment requirements, priority, due context, requester and destination. Printer eligibility can use assigned groups, tags and machine information so work is matched to an appropriate online printer. Your policy should make maintenance or out-of-order state ineligible. SimplyPrint enforces that state for AutoPrint and 1-Click Print; generic queue matching and authorized manual starts remain separate paths that the operating procedure must control. An idle machine in another country is not necessarily a valid match if the part is needed locally, the material is unavailable there, the file has a site restriction, or nobody is present to clear and verify the result. Start with **local queues or local queue groups** and a visible escalation path. Allow cross-site routing only when the organization has decided: - who authorizes the transfer; - whether the file may be accessed at the other site; - who pays for and arranges shipping; - which profile and material are equivalent; - who owns the job after transfer; - how the requester is notified. This policy is more important than whether the interface displays one queue or several. The [print queue](/features/print-queue) supplies grouping, approval and matching tools; the organization supplies the service rule. :::image src="https://cdn.simplyprint.io/library/web/auto/desktop/panel/queue/queue-list-landing.png" alt="SimplyPrint shared print queue with queue groups and pending jobs showing quantities, print times, material, and actions" caption="Queue groups make local workloads visible while retaining a consistent submission and approval workflow."::: :::feature PrintQueueFeatureController::: ## Standardize profiles without hiding local differences Separate three layers: - **Machine truth:** printer model, firmware or connection, nozzle, build surface and installed hardware. - **Approved process:** slicer profile, material profile and settings that the organization has reviewed for a type of work. - **Job request:** the part, quantity, priority, requester and any allowed choices. Machine truth should be updated when hardware changes. Approved profiles should have an owner and a change process. Requesters should choose only the variables the service is willing to support. That prevents a global platform from becoming a collection of site-specific profile names that happen to look similar. Mixed-brand management is valuable because operators can see supported printers together, but it does not make their capabilities identical. A profile for one printer family should not be silently reused on another. Keep the compatibility decision explicit and use queue eligibility to route only to validated combinations. ## Put maintenance and incidents in the same operating model Remote visibility is useful only if an alert leads somewhere. Define an escalation record with: - printer and site; - symptom or device message; - current job and material; - person acknowledging it; - remote action allowed, if any; - local physical action required; - decision to resume, create maintenance, or mark out of order; - requester communication owner. SimplyPrint lets operators report printer problems and link them to maintenance jobs. Starting any maintenance job marks the printer as in maintenance, so AutoPrint and 1-Click Print exclude it until that job is completed or cancelled. Generic queue matching and manual starts are separate paths; authorized maintenance managers can still start a print after a warning, so local procedure must also prevent manual dispatch during service. Schedules can create work by elapsed days, print hours, filament, print count, task threshold or failures. The [fleet maintenance checklist](/articles/3d-print-farm-maintenance-checklist) explains how to choose thresholds without inventing universal service intervals. Across locations, central owners can maintain task definitions while local technicians complete the model-specific procedure and return-to-service test. ## Report centrally, investigate locally Agree on the small set of questions central reporting must answer: - Which sites and printers are available, busy, in maintenance or out of order? - How much print time, material and cost is attributed to each user, group, printer or period? - Which jobs fail or wait, and why? - Which maintenance work is due or overdue? - Where is queue demand exceeding eligible capacity? - Which profiles or printer families need review? Use the [statistics page](/features/statistics) for operational usage and cost views, and the audit trail for security-relevant account actions. Do not turn one dashboard number into an unsupported business conclusion. A site with fewer completed jobs may have longer prints, planned downtime, a different service role or a data-quality problem. The local owner provides the context. ## Integrate at the workflow boundary The REST API and webhooks can connect printer operations with a request portal, project system, service desk or reporting environment. Define the handoff before writing an integration: | Handoff | Good integration question | | :--- | :--- | | Work intake | Which approved request creates or updates a print job? | | Identity | Which system is authoritative for the user's role and site? | | Status | Which job events should update the requester or service desk? | | Cost and usage | Which completed-job fields move into reporting or chargeback? | | Incident | Which printer or job event creates an operational alert? | | Maintenance | Which events require a work order, and which merely notify? | Keep one system authoritative for each field. Avoid a two-way integration in which both systems can independently change priority, identity or completion state without a conflict rule. The [API](/features/api) and [webhooks](/features/webhooks) are interfaces, not a prebuilt ERP or MES integration. ## A phased multi-location rollout Use one representative site to validate the model before expanding: ### Phase 1: inventory and observe Connect a small set of supported printers, apply naming and location conventions, and confirm that status, profiles and local ownership are correct. Do not automate dispatch yet. ### Phase 2: submit and approve Move requests into the queue, define required fields and permissions, and measure why jobs wait or are returned. This finds policy gaps without risking automated routing. ### Phase 3: controlled matching Enable matching for combinations the operators have validated. Put maintenance and out-of-order rules in place before allowing unattended dispatch features. ### Phase 4: add another site Test identity mapping, time zones, local escalation, profile equivalence and reporting. Keep cross-site routing manual until the transfer rule is proven. ### Phase 5: integrate Connect upstream requests or downstream reporting after the platform workflow has stable owners and states. Automating an ambiguous process only makes ambiguity faster. :::related organisation-management/farm-enterprise,print-queue,printer-maintenance::: ## Multi-location readiness checklist - [ ] Every controlled printer is a supported FDM/FFF model and connection, or clearly marked as an uncontrolled virtual machine. - [ ] Every printer has a location, local owner and backup. - [ ] Machine data and approved profiles are separate and owned. - [ ] Requester, approver, operator, technician and administrator rights are documented. - [ ] Identity groups map users to the intended location and role. - [ ] Queue eligibility includes material, profile and operational state. - [ ] Cross-site routing has an authorization and shipping rule. - [ ] Maintenance work removes printers from dispatch. - [ ] Alerts have a local acknowledgement and escalation owner. - [ ] Central reports have agreed definitions and local context. - [ ] API and webhook handoffs each have one authoritative source. - [ ] Cloud, residency and any self-hosted requirement have been scoped with IT. If those checks are complete, a central dashboard becomes useful because it represents an operating model rather than replacing one. Explore [SimplyPrint Enterprise](/enterprise) for multi-location organisation controls, or read [what 3D printing workflow software should own](/articles/3d-printing-workflow-software) before connecting it to MES, ERP, PLM or QMS. :::cta text="Explore multi-location 3D printer management" url="/enterprise":::