Technology & security
Designed around responsibility.
A repair shop has different people handling reception, repairs, parts, and accounts. Our system design treats those responsibilities as boundaries for data access and changes.
These principles describe the product being developed. They are not a certification, service-level guarantee, or announcement that the service is available.
Separate shops, scoped access
The authorization design ties each staff request to an active account and shop membership. Access is checked against the shop, authorised locations, and the record involved.
A record identifier or a link is not permission to access another shop’s data. Checks belong on the server, including lists and related records, rather than relying on hidden buttons in the app.
Permissions reflect workshop responsibilities
The six staff roles are Owner, Manager, Service advisor, Technician, Parts manager, and Accountant. Compatible operational roles may be combined. Each shop has one active Owner, assigned alone; Accountant is also assigned alone to keep financial duties separate.
A person assigned only the Technician role is scoped to assigned work and the information needed to perform it. A subscription does not grant extra staff permissions. Access is checked against current membership and assignment, not just the role recorded at login.
Keep changes and their evidence together
For operations that require audit evidence, the design keeps the business change and its required record in the same transaction. If either part fails, the operation must not leave a partially completed change.
Current record versions are checked before changes are accepted. Protected commands also check retries so that repeating a request does not create a second completed operation. These controls address concurrent work and interrupted connections.
Limit the data each task exposes
Shop staff and vehicle owners have separate access rules. The data returned for a task is limited by its purpose and the person’s relationship to the record.
The audit design records the action, target, and necessary authority context. Passwords, access credentials, and unnecessary copies of customer information do not belong in general logs or audit records. Private files require their own ownership and access checks.
Verify boundaries before release
Our development checks cover allowed and denied actions, attempts to cross shop boundaries, changed staff authority, conflicting edits, and failures during a change. Passing one check does not establish that the complete product is ready for release.
If you identify a security concern, contact us below with a description and steps to reproduce it using synthetic data. Do not include credentials or real customer records.