How FRBOS actually works in production: the service workflow, security, email delivery, hiring, organizations and the administrator checklist.
Everyone
Version 3.0 · Updated 2026-08-18
Platform
What FRBOS is
FRBOS — the FredericRepair Business Operating System — is a technology and service-business operating platform. It manages customers, service requests, dispatch, technicians, repairs, equipment, inventory, organizations, employees, cybersecurity, communications, billing, careers and hiring, technology lifecycle, reporting and QA in one system.
Who it is for: small businesses, service companies, organizations, schools, churches, technology companies and larger organizations.
One canonical service record from the first customer message to the final invoice.
Bilingual English and French across the interface, documents and emails.
Every sensitive action is enforced in the database, not only in the interface.
Customer operations
The service workflow
Purpose: one canonical path for every paid service, whoever starts it. Used by customers, reception, technicians, managers and accounting. Prerequisite: an active service desk and at least one active technician.
1Customer — a signed-in customer submits from the portal, a guest submits from the Support Center, or a walk-in is taken at the service desk.
2Request — the request is written to the single service-request record with a reference (SR-…) and, when a desk is active, a daily queue ticket.
3Queue — the request appears in the Support Queue for reception.
4Reception — reception calls the request and dispatches it to a technician; the FRBOS work order (WO-…) is created at that moment.
5Technician — the technician records the assessment: findings, diagnosis, recommended work, labour hours, parts and expected completion.
6Quote — labour, parts, services and any discount are priced, tax is applied from the organization's tax settings, and the total is stored on the work order.
7Customer approval — the customer approves or declines the quote in the portal. The decision, the timestamp, the customer identity and the signature when provided are stored.
8Repair — work in progress. The database refuses this step when a quote was sent and not approved.
9Completion — work performed, parts used, labour and completion notes are recorded and the request moves to Completed.
10Invoice — the invoice inherits the approved quote values: subtotal, tax and total.
11Customer history — the completed repair, the approved amount and the invoice stay visible to the customer.
Expected result: reference, queue ticket, work order, quote total, approval record, completion timestamp and invoice all exist on the same record and reconcile with each other.
Work in progress, invoice preparation and invoicing are blocked in the database whenever a quote was sent and the customer has not approved it. Refusing in the interface alone is not considered protection.
A request does not appear in the queue immediately.
The queue listens for live updates and also refetches when the window regains focus. Switch away and back, or reload; the record already exists because the confirmation is only shown after the row is written.
An attachment did not upload.
The request is still created and the failed file names are returned to the customer and written to the audit log, so nothing fails silently. Add the file again from the request.
Related modules: Customer portal, Customers / Guests, Support Queue, Technician Operations Center, Equipment, Inventory, Email Health.
Customer and guest security
Registered customers sign in with a verified email address and see only their own requests, repairs, invoices and notifications.
Guests can submit a request without an account; when they later register with the same address, their earlier requests are attached to the new account.
Customer identity is separate from employee identity. Applying, buying or requesting service never creates staff access.
Organizations are separated from each other; organization members see only their own organization's records.
Row-level security is enforced in the database for customer records, requests, work orders, notifications and media.
Repeated failed sign-ins lock the account temporarily, and lockouts, sessions and security events are recorded.
Two-factor authentication applies to staff roles, not to customer accounts. Customer documentation never contains another customer's information.
Technicians and assets
Technician operations
Purpose: give the assigned technician everything needed to diagnose, quote, repair and close a job. Used by technicians and senior technicians. Prerequisite: an assigned work order.
1Open the assigned job from the Technician Operations Center.
2Record findings, diagnosis, recommended work, equipment condition and expected completion.
3Add labour hours, parts and any service lines; attach photos, video or voice notes.
4Send the quote for customer approval and wait for the decision.
5Set Work in progress, then record work performed, parts used and completion notes.
6Complete the job; the service desk record moves to Completed automatically.
Permissions: a restricted technician sees only their assigned requests, work orders and the related customers, and can set only assessment, quote, approval, work, parts and completion statuses.
Reception-only actions such as cancelling, closing or reassigning a request are refused by the database for technicians.
Offline: media and notes captured without a connection are queued locally and synchronized when the device reconnects.
Customer-facing wording is generated from the workflow status, so internal reception vocabulary is never shown to the customer.
Equipment, inventory and lifecycle
Equipment records carry the owner, the organization, the location, warranty, health and lifecycle status from New through Active, Aging, End of life and Retired.
Completing a repair writes a repair event on the asset and updates its last maintenance date.
Inventory tracks stock, reservations and parts consumed by a work order.
Technology lifecycle produces replacement and maintenance forecasts and repair-versus-replace guidance.
Security and email
Security Centre
Two-factor authentication with recovery codes, required for owners, administrators and managers.
Sessions and devices, with administrator force sign-out and inactivity timeout.
Failed sign-in throttling and temporary account lockouts, with unlock recorded in the audit log.
Roles and a configurable permission matrix per module, enforced by a database permission check.
Security events and audit logs for staff, hiring, service desk and administrative actions.
Email Health for delivery evidence.
Roles are never stored on a profile record. Role checks run through a dedicated role table and a security-definer function, so a user cannot raise their own privileges.
Email and delivery tracking
Purpose: prove what FRBOS sent and what happened to it. Used by administrators and managers.
1An FRBOS event happens, for example a request is created or a quote is ready.
2A delivery record is written before the provider is called, with the recipient, subject and event type.
3The message is sent through Resend from the verified sending domain.
4The provider message id is stored on the record and the status becomes Sent.
5Signed provider webhooks move the same record to delivered, delayed, bounced, complained or failed.
Failed and stalled sends are visible in Email Health and can be retried a bounded number of times; a retry never invents a new recipient.
In-app notifications are the redundancy channel: an email failure never removes the operational record or the notification.
Webhook status requires the signing secret to be configured; without it, records stop at Sent.
Provider keys and webhook signing secrets are never displayed in FRBOS or in this documentation.
Careers and hiring
Careers and hiring
/careers — the public bilingual application form with resume and video upload.
/hiring — the internal pipeline for reviewing, interviewing, assessing and deciding.
/candidate-invite and /candidate-signin — token-based access to the candidate portal.
/candidate — the candidate's own application status and timeline.
1Applicant submits an application and receives a reference.
2Review, then shortlist.
3Interview is scheduled and the outcome is assessed.
4A decision is recorded and the candidate may be marked Selected.
5Hire Candidate: an authorized user chooses the FRBOS employee role and employment details.
6An employee invitation is emailed to the candidate.
7The candidate accepts and signs in; only then does the employee relationship become active in Team.
Applying for a job never creates an employee account. Only an explicit hiring decision, an employee invitation and a confirmed acceptance create the employee relationship. Resumes and videos are stored privately and every document opening is audited.
Employment History
Application and position applied for.
Interview records and assessment.
Decision, who decided and hiring approval.
Employee role, start date, department, supervisor and employee identifier.
Team profile link, role changes and current employment status.
Employment history is protected HR information. It is visible only to users holding hiring permissions and is never shown in the candidate portal or in public pages.
Administration
Organizations and subscriptions
Onboarding captures organization type, country, region, currency and timezone.
A subscription carries the plan, the trial period, seat and usage limits and the expiry date.
Limits are checked when new records are created; expiry restricts access, it does not erase records.
When a trial or subscription expires, organizational data is retained. FRBOS does not delete customer, asset, service or invoice history automatically.
Internationalization
Interface languages: English and French are complete; Spanish, Portuguese, Arabic and Swahili are available and still being extended.
Country registry with region, currency, phone format and timezone used for organizations and pricing.
Tax settings are configured per organization; Canadian provincial presets include Ontario at 13 percent.
A country appearing in the registry means the configuration exists. Verified end-to-end operation, including tax and billing, is confirmed today for Canada only.
QA Sandbox
Purpose: let administrators exercise the platform safely. Used by administrators and owners. Prerequisite: an administrator account with QA access.
Checks cover database integrity, security rules, authentication, roles, bilingual content, document generation and AI availability.
Manual test flows: create a test customer, submit a request, dispatch it, quote it, approve it, complete it, invoice it, then test careers, hiring and employee invitation with a dedicated test address.
Mark test records clearly, for example a QA prefix in the name, and use a dedicated test mailbox so QA email never reaches a real customer.
QA runs against the production database. Test records are real records: they appear in the queue, in reports and in email history until an administrator archives or cancels them.
Administrator checklist
1Create the organization and complete its profile: type, country, region, currency and timezone.
2Review Roles and Permissions and adjust the module matrix.
3Invite employees from Team; there is no public staff sign-up.
4Configure the service desk: name, categories, ticket prefix, contact details and welcome text.
5Configure pricing and labour rates.
6Configure tax for the province or country.
7Review notification settings and the sending domain.
8Configure security: two-factor for privileged roles, session timeout and lockout policy.
9Run a test customer request and confirm it reaches the Support Queue.
10Dispatch it and run the technician assessment.
11Build the quote and confirm the tax and total.
12Approve it from the customer portal.
13Complete the job and create the invoice; confirm the invoice matches the approved quote.
14Check Email Health for the delivery records of that run.
15Review the audit log and the QA results.
Contact support
Our Ottawa–Nepean team answers in English and French.