QWorks is designed for on-premise deployment. Where it runs, which identity infrastructure it uses, where each piece of data sits and how changes move between environments are all scoped to your organisation’s architecture and security standards. This page is the starting frame for that scoping.
QWorks is not a single sealed box; it is deployed as four separable layers. Each layer sits inside your own network, on your own servers, under your own policies.
Complaint and any other modules brought into service run on the same application. Horizontal scaling and load distribution are planned around your existing application server standard.
Quality cases, evidence files and the audit trail sit in your own database and file infrastructure. Data residency is wherever your servers are; no copy leaves that boundary.
Connections to ERP, MES, PLM and document systems are established by whichever method you permit. Direction, frequency and scope of each connection are defined one by one during deployment.
User identity does not have to live as a separate account store inside QWorks; it can be bound to your existing directory and single sign-on infrastructure.
A quality operation produces records that go into audits. Configuration changes, version upgrades and integration trials are therefore not tested against live data; they move through separate environments.
QWorks does not invent a new world of permissions. It takes your organisational structure, roles and data boundaries as given, and applies the same rule in every module.
Users sign in with their existing corporate accounts. Password policy, multi-factor authentication and account lifecycle stay in your infrastructure.
Quality, production, engineering, logistics, supplier quality and management roles are defined separately. What a role cannot see does not appear in its interface.
Access depends not only on role but on context: it can be limited by site, customer, product group and organisational unit.
External actors such as suppliers are scoped to reach only their own cases and the evidence requested from them.
Because QWorks runs the quality operation, the record that accumulates on it is the record used in audits. The integrity and continuity of that record is a deployment matter.
Who changed what, when, on what grounds and with which evidence — the history of actions on a case is held by the system and is not corrected by hand afterwards.
Backup frequency, retention and restore targets are bound to your existing database and file backup policy; QWorks does not build a separate backup island.
The recovery scenario is written as part of your disaster recovery plan; target times are set by your own service levels.
In an enterprise purchase the biggest risk is not the software but the decision to bring everything into service at once. QWorks starts with the priority process and widens in a controlled way on the same backbone.
The architecture, network, identity and integration inventory are mapped together. The deployment topology is written in this meeting.
Environments are established; roles, routes and SLA profiles are configured to your own process definitions.
Your own teams verify in the acceptance environment; the pilot closes with a decision meeting whose date is fixed from the start.
New versions reach test and acceptance first. The upgrade schedule is planned around your maintenance window; no upgrade is imposed on a fixed date.
Because QWorks is deployed on premise, quality cases, evidence files, the audit trail and user records sit on your own infrastructure. That data is not tied to a subscription relationship, a third-party cloud account or the provider’s operational access.
This is a positioning choice rather than a technical one. In the automotive and aerospace supply chain, customer-specific requirements, export control and customer audits often ask directly where data sits. That question is answered in the architecture of the product.
Explore the integration approachThe four questions asked most often before a technical meeting.
QWorks is designed for on-premise deployment. It can run in your own private cloud environment; what matters is who controls the server, not its physical location. A multi-tenant shared SaaS environment is not offered.
Yes. QWorks needs no outbound connection in order to run. In a closed-network deployment, version updates and support access are planned through whichever controlled method you permit.
Deployment and support access are defined by your own policy. Permanent remote access is not required; when support is needed, the scope, duration and logging of that access are set by you.
Corporate directory and single sign-on integration are within deployment scope. Which protocol is used and how roles are mapped are determined with your IT team during the scoping meeting.
Let us scope against your network topology, identity infrastructure, environment standard and integration inventory. We answer RFI and security questions directly with the technical team.
