Architecture Overview

This page provides a high-level overview of the TrackQUAL platform architecture. It is intended to help customers, partners, and stakeholders understand how the main parts of the platform fit together, how customer environments are separated within the service, and how the platform is structured to support security, resilience, and controlled operations.

This page is intentionally high level. It is designed to explain the shape of the platform and its main trust boundaries without disclosing confidential implementation detail, security-sensitive configuration, or internal operational procedures.

1. Platform Summary

This section explains the overall structure of the platform.

TrackQUAL is a cloud-based, multi-tenant software platform used to support returns, inspections, approvals, repairs, customer communications, and related operational workflows.

At a high level, the platform is structured around:

• a public-facing layer for brochure content, documentation, legal pages, and public journeys;
• an authenticated application layer for day-to-day operational workflows;
• a tenant-aware access and data model for controlled separation between customer environments;
• managed Azure-hosted application, database, and storage components; and
• supporting integrations for communications, billing, anti-abuse controls, and related service functions.

2. High-Level System Narrative

This section explains the platform in a simple end-to-end flow.

A simplified view of the TrackQUAL platform is as follows:

1. A user, customer contact, or public visitor accesses the TrackQUAL website or application.
2. Public web traffic is handled through the platform's Azure-hosted delivery layer, including Azure Front Door where used for routing, entry-point control, and edge handling.
3. Requests are served by the TrackQUAL web application running within Azure App Service.
4. Authenticated users interact with the application layer to create, review, update, and manage workflow records.
5. Structured operational data is stored in Azure SQL Database.
6. Documents, images, and related uploaded assets are stored in cloud storage services used by the platform.
7. Supporting services may be used for email delivery, billing, captcha protection, translation, and related operational functions.

This model allows TrackQUAL to keep the public experience, application logic, structured data, file storage, and supporting service integrations logically distinct while still operating as a unified service.

3. Public Layer vs Application Layer

This section explains the distinction between the public website and the authenticated product.

TrackQUAL distinguishes between its public-facing content layer and its authenticated application layer.

The public layer is used for:

• product information;
• pricing and marketing pages;
• documentation and trust content;
• legal and policy pages; and
• public forms or other pre-login interactions.

The application layer is used for:

• returns and repair workflows;
• inspection and approval processes;
• customer and tenant administration;
• user access, permissions, and session handling;
• operational records, attachments, and workflow actions; and
• customer-facing or internal portal activity where supported.

This separation helps keep public content concerns distinct from customer data, operational workflows, and authenticated platform functions.

4. Azure Hosting Layout

This section explains the main Azure hosting components in the architecture.

TrackQUAL is designed around a Microsoft Azure-hosted architecture. At a high level, the core service layout includes:

• Azure Front Door for public entry-point routing, traffic handling, and related front-end delivery functions where configured;
• Azure App Service for hosting the web application and serving both public and authenticated platform experiences;
• Azure SQL Database for structured operational and account-related data;
• Azure storage services for uploaded files, documents, images, and related object storage needs; and
• Azure Communication Services Email for service-related outbound email, with optional alternative email provider support where configured.

This Azure-based model allows TrackQUAL to use managed infrastructure components for application hosting, database services, storage, and supporting operational capabilities.

5. High-Level Component Stack

This section summarises the main component layers in the platform.

The platform can be understood as a small number of connected architectural layers:

• presentation layer for website pages, documentation, and application user interfaces;
• application layer for workflow logic, access control, business rules, and operational actions;
• identity and session layer for sign-in, session handling, role-aware access, and tenant context;
• data layer for structured records, settings, and related service data;
• storage layer for file and object-based content such as attachments or uploaded assets; and
• integration layer for billing, email, anti-abuse, translation, and similar supporting services.

This layered model helps keep responsibilities clear across the system and supports more controlled evolution over time.

6. Tenancy Segregation Model

This section explains how customer environments are separated within the service.

TrackQUAL is designed as a multi-tenant platform. This means the service supports multiple customer or organisational environments on a shared application foundation while applying tenant-aware controls to restrict access and visibility appropriately.

At a high level, the tenancy model includes:

• tenant-linked user accounts and user context;
• tenant-aware access rules within the application;
• controls over which records, workflows, and administrative functions a user can access;
• support for tenant-specific branding and configuration in relevant areas; and
• separate handling of elevated administrative capabilities where required.

The aim of this model is to allow customers to use a common service platform without exposing one customer's operational data or controls to another customer's users.

7. Trust Boundaries

This section explains the major boundaries that matter in the architecture.

TrackQUAL's architecture is shaped by a number of important trust boundaries. These include:

• the boundary between public, unauthenticated interactions and authenticated platform access;
• the boundary between one tenant's user and data context and another tenant's environment;
• the boundary between application logic and underlying database or storage services;
• the boundary between TrackQUAL's core service and third party supporting providers; and
• the boundary between standard customer access and elevated administrative or support activity.

These trust boundaries are important because they influence how access, identity, routing, monitoring, and data handling are designed throughout the platform.

8. Tenant-Aware Design

This section explains how tenancy is reflected in the application design itself.

Tenant awareness is not treated as a cosmetic feature. It is a core architectural concept in the way TrackQUAL handles users, access context, routing, and data visibility.

At a high level, tenant-aware design means that the platform takes account of customer or organisational context when determining:

• which environment a user is operating within;
• which records and workflows they are allowed to access;
• which actions they are allowed to take;
• which branding or configuration rules apply; and
• how administrative capabilities are restricted and controlled.

This helps support appropriate logical separation within a shared-service architecture.

9. Database and Storage Layers

This section explains how the platform treats structured data and stored files.

TrackQUAL uses different storage approaches for different kinds of information.

At a high level:

• Azure SQL Database is used for structured operational records, account-linked data, workflow state, and related service information;
• cloud object storage is used for files, uploaded images, documents, and other attachment-style content;
• public content data, such as documentation and resource content, is managed separately from core operational workflow data; and
• settings and supporting metadata are handled according to their role in platform operations and service delivery.

This separation helps align different storage technologies with different data types and operational requirements.

10. Supporting Services and Integrations

This section explains the surrounding services that support the platform.

TrackQUAL uses selected third party and Azure-native supporting services to provide or support specific capabilities. These may include:

• billing and subscription services;
• transactional email delivery;
• captcha and anti-abuse controls for public-facing journeys;
• translation-related functionality where enabled; and
• public-site analytics and tag-management tooling where used.

These services support the platform, but the core application, customer workflows, and main service data remain centred around the TrackQUAL application and its Azure-hosted data environment.

11. Security and Architecture Relationship

This section explains how this page relates to the Security Overview.

This Architecture Overview should be read alongside the TrackQUAL Security Overview. The Security Overview focuses on access controls, authentication, monitoring, backups, incident handling, and related safeguards. This page focuses more on the shape of the platform, its layers, its hosting model, and its trust boundaries.

There is natural overlap between security and architecture. For example, tenant-aware design, trust boundaries, hosted service selection, and component separation are architectural choices that also support security outcomes.

12. Resilience and Operational Considerations

This section explains how the architecture supports continuity.

The architecture is intended to support practical operational resilience through managed hosting components, structured data services, file storage separation, supporting monitoring, and backup and recovery planning.

Further detail on service availability, backup, restore, monitoring, and incident handling is provided separately in Availability, Backup and Incident Response.

13. Related Documents

This section points readers to the related trust pages.

This page should be read alongside:

• Security Overview;
• Availability, Backup and Incident Response;
• Data Protection and Data Flows;
• Subprocessors; and
• Data Processing Addendum, where applicable.

14. Contact

If you require additional information about TrackQUAL's platform architecture, service design, or technical assurance position, please contact us.

Apperley Holdings Ltd. trading as TrackQUAL
Company number: 15798690
Burcombe Road, Chalford, GL6 8BH
Email: info@trackqual.com
Telephone: 01453 374453