Customer, vehicle and work-order data need control at every stage. Roles and permissions help limit access to the information required for each job.
Company, customer and vehicle data needs control at every step of the process - from a user’s role to a partner’s access. Below are the nine areas we work on. Some are constant rules of how the platform works, some depend on the specific rollout and operator configuration - we separate them plainly instead of promising readiness where it isn’t there yet.
These follow from the product’s architecture and hold regardless of the specific rollout.
Users receive access matching their role: front desk, service advisor, mechanic, administrator or fleet manager. Permission scope is granted deliberately and can be audited. The most sensitive financial decisions require a separate, single-use identity confirmation - without it the operation is refused, not waved through.
Access to data is limited to the organisation, location, roles and scopes needed to do the work. A model with multiple locations requires operational data to be separated and visibility between process participants to be controlled.
Every organisation works on its own, separate database created when it is onboarded - not on one shared database where every customer’s data sits in the same tables. Which database a request uses is decided by the organisation context resolved on every call.
Sign-in, the APIs and webhooks carry request-rate limits, shared across every instance of the service and switched on in the production environment. We do not publish the thresholds themselves - knowing them would only make them easier to work around.
Key actions in the vehicle-service process - status changes, cost decisions, partner access and integrations - leave a reconstructable trail in the work order’s history. We extend the operation trail alongside each new platform module.
These depend on the specific organisation, environment and contract - we confirm them during rollout, not upfront in public.
The platform runs on Microsoft Azure cloud infrastructure. The region, configuration and environment details for a specific organisation are confirmed as part of that organisation’s rollout - we do not publish them upfront for every customer.
Customer, vehicle, work-order and partner data requires clearly defined roles, legal bases for processing, access scope and retention periods. The duties of the controller, the operator and end users are set out in the rollout documents and the contract for that organisation.
Backups and data-recovery mechanisms are part of the platform’s architecture. Target retention and recovery-time parameters for a specific organisation are confirmed in the contract - we do not publish them upfront without formal confirmation.
We handle security reports through a documented process with response times set by the severity of the event. The detailed scope, including response times and contacts for a given organisation, is agreed in the contract.
We do not use certifications or compliance statements that no document backs. The scope of security mechanisms, the duties of each party and the data-processing terms are agreed and confirmed for each specific rollout.
A short walkthrough against your processes: what can be joined up, what can be simplified, and what is better left alone.