RepairTrack is designed to manage the full lifecycle of equipment handling, from receiving goods into inventory through repair documentation, testing, reporting, review, and administration.

The app is structured around three main operational areas: Inventory Management, Repair Logs, and Test Reports. These work together so that physical equipment, technical findings, and output documentation remain linked to the same unit.

In practice, this means a user can receive a unit, store it with traceable stock data, create a repair record against that unit, attach technical evidence, record testing, send the work for review, and later retrieve the history for reporting or training.

• Home dashboard for quick access to main actions.
• Inventory workflows for intake, identification, and stock location tracking.
• Repair workflows with fault diagnosis, repair work, and root cause capture.
• Test reporting with structured line items, notes, images, QR-ready sharing, and report viewing.
• Admin tools for master data, users, integrations, logs, and release messaging.
• Help and training content for onboarding, usage guidance, and mobile installation.

The Home page functions as a launch area for the most common tasks. Depending on the user role, it can show actions such as Receive Goods, Browse Inventory, New Repair Log, Browse Repair Logs, New Test Report, Browse Test Reports, Equipment Knowledge, and Pending Reviews.

The top navigation gives access to Home, Admin, and Help, plus the user menu for preferences and logout. The company switcher allows users with multiple memberships to move between organisations.

The Home page is intentionally role-aware. A technician may mainly see documentation and repair shortcuts, while an admin may also use the page as an entry point to logs, settings, credit tools, and update messaging.

• Quick actions reduce the number of clicks for daily operations.
• Pending review cards highlight reports needing reviewer action.
• Version update messages can appear once after login when a new release notice is active.
• The navigation bar stays consistent so users can move quickly between operational areas.
• The user menu centralises logout, theme, language, and notification-related actions.

Inventory Management is the intake and traceability layer of the application. It stores received equipment records before, during, and after repair activity.

Typical captured information includes organisation, client, OEM, equipment name, part number, serial number, customer reference, condition grade, stock location, label image, equipment image, and external test report files.

This area matters because repair quality depends heavily on identifying the exact unit and linking the right evidence to it. Inventory is therefore more than a stock list: it is the foundation for traceable repair history.

• Receive Goods creates structured inventory records.
• Browse Inventory supports search, filter, sort, grouping, and favorite saved views.
• Inventory records can link to repair logs and test reports.
• Stock Location IDs support physical retrieval from racks, shelves, and columns.
• Condition grades document physical appearance independently from electrical fault severity.
• Images captured at intake help preserve the original state of the unit.

The Receive Goods process is used when a unit first enters the system. The goal is to register enough information so the item can be identified, stored, and located later without ambiguity.

Users typically record the client, OEM, customer reference, part number, serial number, condition grade, stock location, and supporting photos. If label photos are added, they provide a permanent visual reference for later verification.

• Capture the incoming unit before repair work begins.
• Assign condition grade based on visible physical state.
• Store stock location immediately so the item remains traceable.
• Preserve label and equipment images as evidence.
• Prepare the unit for later linkage to repair logs and test reports.

Browse Inventory provides a searchable working view of all received items. Users can sort by received date, client, OEM, part number, serial number, condition, stock location, and reference fields.

Grouping lets teams organise records in a way that suits their workflow, for example by client, OEM, part number, or another logical field. Favorite views make those preferred layouts reusable.

• Search quickly by serial, part number, or stock location.
• Filter by client when handling multi-client operations.
• Group large inventories into more practical operational clusters.
• Save favorite views for repeated daily use.
• Edit or delete records directly where permissions allow.

Repair Logs document the technical journey of a unit from symptom through repair and review. This is the core knowledge-capture area of the system.

The workflow includes equipment confirmation, Level 1 diagnosis, repair work, Level 2 root cause, and review. Reports can also include images, annotated PCB locations, replaced components, curve tracer details, test results, time spent, peer review data, and final publication status.

Because reports are structured, the app makes it easier to compare similar failures across units and preserve engineering knowledge that would otherwise stay in personal notes or memory.

• Level 1 diagnosis records the visible or functional symptom.
• Repair Work captures what was done and which parts were used.
• Level 2 root cause identifies the actual failed cause after investigation.
• Review ensures reports are checked before approval or publication.
• Auto-save and draft recovery reduce the risk of lost documentation.
• Status values help teams track progress from in-progress to published or rejected.

Level 1 Diagnosis focuses on the symptom observed before or during the investigation. It is intentionally different from root cause. At this stage the user is documenting what the equipment is doing wrong, not yet what component has failed.

Using standardised fault codes improves consistency and makes searches across reports more reliable. Users can also capture notes and extra contextual information where the code set supports it.

• Use structured fault symptom codes for consistent documentation.
• Add supporting notes to clarify unusual behaviour.
• Capture the operational symptom before the solution is known.
• Improve later filtering and knowledge reuse across reports.

Repair Work is where the user explains what action was taken. This can include component replacement, recalibration, cleaning, soldering, firmware work, rewiring, or another method defined in the app.

Where parts are used, the report can capture part numbers, names, quantities, package details, PCB references, coordinates, datasheet links, and related evidence. Level 2 then records the true root cause discovered through diagnosis.

A key visual tool in this step is the PCB Annotator. When a replaced component is recorded, the engineer can upload a photo of the PCB and draw directly on it to pinpoint the faulty or replaced component, saving an annotated image that stays attached to the report. This makes the failure location unambiguous for reviewers and future engineers, who can see exactly which part on the board was addressed rather than relying on a reference designator alone.

To make sure component names match the industry-standard naming conventions, each replaced part row has an online Component Lookup. The engineer enters a manufacturer part number (MPN) and the system queries live supplier databases (Nexar/Octopart), returning the official part name, type, package, datasheet, and description. Confirming the lookup fills these fields automatically and guarantees the report refers to the exact, recognised component name instead of a free-text guess — important for peer review, future searches, and parts ordering.

The bottom of the Repair Work step includes a mandatory Final Repair Checklist that must be completed before a report is considered finished. This checklist ensures mechanical and sealing integrity is verified on every unit, not just the electrical fix. The items confirm that thermal paste was inspected and reapplied where necessary, screws were secured and locked with Loctite, missing screws were checked for, no loose screws remain inside the enclosure, and water sealant was applied directly to the water ridge/groove. Completing these checks protects against rework caused by vibration, overheating, or moisture ingress after the unit returns to service.

• Record what repair method was used.
• Document exactly which components were replaced or repaired.
• Preserve technical reference details for future repeat repairs.
• Separate the performed action from the underlying root cause.
• Complete the Final Repair Checklist to verify thermal paste, screws, Loctite, and water sealant.
• Support engineering learning by showing not just what fixed the issue, but why the failure happened.

Test Reports store structured testing evidence separately from Repair Logs while still remaining tied to equipment records in inventory.

Saved reports can contain report names, uploaded dates, code identifiers, line-by-line test entries, notes, images, and viewer access through dedicated report pages.

This separation is useful because testing and repair are related but not identical activities. A unit may be tested before repair, after repair, or independently for customer or quality reasons.

Clients have live, direct access to the platform. By searching for the equipment serial number, a client can retrieve the full history of the asset — including the detailed, finalized L3 test report data — without needing a manual export. This ensures complete visibility and auditability at any time.

• Create new test reports from inventory-linked equipment.
• Edit and review saved reports later.
• Use public or structured views where enabled.
• Track testing history independently from diagnosis and repair documentation.
• Capture clear line-by-line results with notes and evidence.

The app includes extensive search and filtering support to locate records quickly.

• Repair Logs can be filtered by status, engineer, equipment, and fault code.
• Inventory can be searched by serial number, part number, stock location, and client filters.
• Component lookup tools help enrich repair data with part details such as descriptions and datasheets.
• Saved grouping preferences in Browse Inventory support repeatable operational views.
• Structured data makes later reporting and audits much easier.

RepairTrack supports visual evidence and structured technical attachments throughout the process.

• Upload label images and equipment images during receiving.
• Add repair photos to support findings.
• Use PCB annotations to point to damaged or replaced areas.
• Store curve tracer setup details and before/after trace images.
• Attach external test reports to inventory records and repairs.
• Strengthen knowledge transfer by combining text with technical evidence.

Peer review is mandatory. No repair report is considered final or published until a designated peer reviewer has formally signed off on it.

The reviewer must rate the quality of the repair report on a scale of 0 to 5. If the score is below 4, the report is sent back and the engineer must edit and improve it — addressing the reviewer's feedback — before it can be submitted for review again.

• Reports are assigned to peer reviewers before they can be finalised.
• Reviewers rate report quality (0–5), add comments, and approve or reject.
• A score below 4 triggers a mandatory rework loop: the engineer improves the report and resubmits.
• Review conversations are stored for collaboration.
• Notification records alert users about review requests and messages.
• Home page widgets and user menu indicators make pending work visible.
• Quality review improves consistency across engineers and teams.

The Admin Panel centralises application configuration and operational oversight.

• Condition Codes management.
• Fault and Root Cause Codes management.
• Equipment list management and equipment type setup.
• User management and membership-related controls.
• Login Logs and Report View Logs.
• OEM, Client, Organisation, and Integration management.
• Version Manager for release/update messages.
• Admin exports such as Data Model PDF and AI Product Deck source file.

The Version Manager allows admins to publish a release message shown once to each user after login. Each message includes a title, version label, and formatted content so teams can be informed of new features or process changes.

Roles define who can manage settings, create reports, receive goods, or review work. The app also supports installation on Android and iPhone for faster mobile access in operational environments.

The Help area provides embedded guidance for workflows, condition grading, exports, peer review, navigation, and installation steps. Together, these features make the platform easier to roll out across technical teams.

• Version messages keep users informed of changes.
• Role-based access protects sensitive admin functions.
• Mobile installation supports workshop and field use.
• The Help page acts as embedded onboarding documentation.

The Home page functions as a launch area for the most common tasks. Depending on the user role, it can show actions such as Receive Goods, Browse Inventory, New Repair Log, Browse Repair Logs, New Test Report, Browse Test Reports, Equipment Knowledge, and Pending Reviews.

The top navigation gives access to Home, Admin, and Help, plus the user menu for preferences and logout. The company switcher allows users with multiple memberships to move between organisations.

• Quick actions reduce the number of clicks for daily operations.
• Pending review cards highlight reports needing reviewer action.
• Version update messages can appear once after login when a new release notice is active.

Inventory Management is the intake and traceability layer of the application. It stores received equipment records before, during, and after repair activity.

Typical captured information includes organisation, client, OEM, equipment name, part number, serial number, customer reference, condition grade, stock location, label image, equipment image, and external test report files.

• Receive Goods creates structured inventory records.
• Browse Inventory supports search, filter, sort, grouping, and favorite saved views.
• Inventory records can link to repair logs and test reports.
• Stock Location IDs support physical retrieval from racks, shelves, and columns.
• Condition grades document physical appearance independently from electrical fault severity.

Repair Logs document the technical journey of a unit from symptom through repair and review. This is the core knowledge-capture area of the system.

The workflow includes equipment confirmation, Level 1 diagnosis, repair work, Level 2 root cause, and review. Reports can also include images, annotated PCB locations, replaced components, curve tracer details, test results, time spent, peer review data, and final publication status.

• Level 1 diagnosis records the visible or functional symptom.
• Repair Work captures what was done and which parts were used.
• Level 2 root cause identifies the actual failed cause after investigation.
• Review ensures reports are checked before approval or publication.
• Auto-save and draft recovery reduce the risk of lost documentation.

Test Reports store structured testing evidence separately from Repair Logs while still remaining tied to equipment records in inventory.

Saved reports can contain report names, uploaded dates, code identifiers, line-by-line test entries, notes, images, and viewer access through dedicated report pages.

• Create new test reports from inventory-linked equipment.
• Edit and review saved reports later.
• Use public or structured views where enabled.
• Track testing history independently from diagnosis and repair documentation.

The app includes extensive search and filtering support to locate records quickly.

• Repair Logs can be filtered by status, engineer, equipment, and fault code.
• Inventory can be searched by serial number, part number, stock location, and client filters.
• Component lookup tools help enrich repair data with part details such as descriptions and datasheets.
• Saved grouping preferences in Browse Inventory support repeatable operational views.

RepairTrack supports visual evidence and structured technical attachments throughout the process.

• Upload label images and equipment images during receiving.
• Add repair photos to support findings.
• Use PCB annotations to point to damaged or replaced areas.
• Store curve tracer setup details and before/after trace images.
• Attach external test reports to inventory records and repairs.

The peer review system helps standardise quality before reports are considered complete.

• Reports can be assigned to peer reviewers.
• Reviewers can rate reports, add comments, and approve or reject.
• Review conversations are stored for collaboration.
• Notification records alert users about review requests and messages.
• Home page widgets and user menu indicators make pending work visible.

The Admin Panel centralises application configuration and operational oversight.

• Condition Codes management.
• Fault and Root Cause Codes management.
• Equipment list management and equipment type setup.
• User management and membership-related controls.
• Login Logs and Report View Logs.
• OEM, Client, Organisation, and Integration management.
• Version Manager for release/update messages.
• Admin exports such as Data Model PDF and AI Product Deck source file.

The Version Manager allows admins to publish a release message shown once to each user after login.

• Each message includes a title, version label, and rich formatted content.
• Only one version message is active at a time.
• Users who have already seen a specific update do not see it again.
• The editor supports formatting and emoji insertion.

Different roles shape how users interact with the system.

• Super Admin: broad cross-organisation visibility and export access.
• Admin: management of users, settings, and master data.
• Editor: create and update repair logs and related records.
• Receiving Agent: focus on intake and inventory workflows.
• Reviewer: assess assigned reports and provide quality feedback.

The Scope 3 Emissions view translates repair activity into circular-economy impact. Every repair that extends an asset's life avoids the embodied carbon of manufacturing a replacement unit.

• Emissions are calculated from the equipment weight, the client's CO₂ emission factor, and the expected additional years of use after repair.
• Aggregated totals show avoided CO₂e across the organisation and per client.
• Charts break down impact by equipment type, client, and time period.
• The figures support sustainability reporting and demonstrate the environmental value of repair-over-replace.

The app can be installed on Android and iPhone for faster access from the home screen. Installation instructions are already provided in the Help page for both Chrome on Android and Safari on iPhone.

This makes the system easier to use in workshop, warehouse, and field environments.

The Components & Consumables section lets engineers build a shopping list of parts required for a repair, with direct integration to major electronic component distributors.

• Engineers create a shopping list of components and consumables needed for their repairs.
• The platform integrates directly with large electronic component warehouses such as Digikey, Mouser, and RH (Rutronik).
• Components can be looked up by manufacturer part number, with live pricing and stock availability.
• Selected items are added to a shared organisation shopping basket for procurement.

The Help area provides embedded guidance for workflows, condition grading, exports, peer review, navigation, and installation steps.

This PDF version is intended to support formal onboarding and documentation handover in a more printable format.