Manage the entire lifecycle of your repair shop's employees: invite, edit role and shop, deactivate, or remove a staff account, while keeping their activity history always available.
From Company > Staff users you have full control over the employee lifecycle in the system: not just the initial invite of a new technician or front-desk employee, but also editing their details, temporarily deactivating their access, and permanently removing an account when an employee leaves the company.
Why it matters for a repair shop
A smartphone and PC repair shop often deals with turnover and seasonality: technicians who train alongside colleagues before being hired permanently, seasonal staff for busy periods, cover for sickness or holidays, internal role changes when a technician becomes a shop manager. Every repair, POS sale, or chat message stays linked to the employee who recorded it: that traceability is valuable in case of a customer dispute, a tax audit, or simply to understand each technical staff member's workload.
Well-structured staff management is therefore one of the foundations of a reliable repair shop management system: it lets you grow the team without losing control of who can access the software, safely handle departures, and keep the operational history intact even as people change.
In practice
A new employee is added through an invite: they're assigned a role/uLevel, which sets their general access scope in the system, and a default working shop. From that point the employee appears in the staff list with their main details, assigned role, and account status. From this same list you can also reach the granular module-and-shop permission configuration described in the dedicated staff permissions article, to further refine exactly what that employee can view, create, edit, or delete.
From each employee's record you can edit name, contact details, role/uLevel, and assigned shop at any time: useful, for example, when a technician changes shop or gets promoted to manager. An account can be deactivated without deleting it, immediately blocking access to the system while keeping their entire activity history intact: repairs handled, sales recorded, and chat messages sent all remain viewable, but the employee can no longer log in until the account is reactivated.
Removal, unlike deactivation, is meant for permanent departures from the company: the account can no longer be used and cannot be reactivated afterwards. This distinction between deactivation and removal is especially useful in a repair shop with staff turnover or seasonal collaborations: you can suspend the access of an employee who's temporarily away and reactivate them on their return, without recreating their profile from scratch or losing their operational history.
Quick guide
- Go to Company > Staff users.
- Invite a new employee by entering their details, role/uLevel, and default shop.
- Open an existing employee's record to edit their name, contact details, role, or shop.
- Reach the granular module-and-shop permission configuration from here if needed.
- Deactivate the account of an employee who's temporarily away, keeping their history viewable.
- Reactivate the account as soon as the employee is back on duty.
- Permanently remove the account only when the employee leaves the company for good.
Real-world use cases
Seasonal reinforcement. A repair shop hires two fixed-term technicians for the peak period tied to the back-to-school rush, when smartphone and PC repairs spike. At the end of the season, instead of removing the accounts right away, the owner deactivates them: if the same staff are useful again next season, reactivating them keeps the history of repairs they already handled.
Maternity cover. An employee on maternity leave is temporarily replaced by a colleague hired for the purpose. Her account stays deactivated during the absence, so no one can access it, but the repair and sales data she handled stays linked to her name for the whole period, ready to be reactivated when she returns.
Internal promotion. A particularly reliable workshop technician is promoted to manager of a new shop the company has opened. The owner updates their role and default shop from their record, and adjusts granular permissions from there too to reflect the new responsibilities, without having to create a brand-new account.
Tips and best practices
Always prefer deactivation over removal whenever there's even a chance the employee will come back to work for you: removal is meant to be permanent. Update role and shop promptly whenever an employee changes duties, so permissions and reports stay consistent with their actual position. Periodically review the staff list to spot former employees' accounts that are still active and should be deactivated. Involve shop managers in periodically reviewing the active staff list too, so information about who's really working at each outlet stays reliable and up to date.
Common mistakes to avoid
Never remove an account just to "tidy up": once removed, the employee can no longer be reactivated, while deactivation achieves the same practical result — blocking access — while staying reversible. Don't forget to deactivate the account of an employee who leaves the company: a forgotten active login is a security risk for customer and repair data. Don't confuse staff management with granular permissions: here you manage who exists as a user and their status, while exactly what they can do is configured in the permissions section.
Frequently asked questions
What's the difference between deactivating and removing an employee? Deactivation blocks access while keeping the history and lets you reactivate the account later; removal is instead permanent and irreversible.
Can I assign an employee to more than one shop? The shop set in their record determines where the employee mainly works; detailed access to individual modules and shops is configured in the staff's granular permissions.
What happens to a deactivated employee's history? It remains fully viewable: repairs, sales, and messages recorded under their name are neither deleted nor modified.
Can I reactivate an employee removed by mistake? No, removal is permanent: if you need to bring that person back, they must be invited again as a new staff user.
Are the role/uLevel and granular permissions the same thing? No, the role sets the general access scope in the system, while granular permissions, configurable by module and shop, further refine the details.
Does a deactivated employee still receive notifications or messages? No, as long as the account stays deactivated the employee can't access the system or receive operational notifications.
