FabTrk Team Roles & Permissions Guide

Team Roles and PermissionsHow FabTrk decides who can do what: the built-in shop roles, the permission model behind them, and how to build your own roles.FabTrk scopes everything to your organization first: nobody outside your org can see your projects, period. Inside the org, roles decide what each person can do. This guide explains the model and the defaults. How permissions work Permissions are simple verbs on resources: create , edit , and delete , applied to projects, tasks, inventory, documents, time logs, team members, and customers, plus a separate manage settings permission for org level configuration. A role is just a named bundle of those permissions. Every team member has a role; what they can do is exactly what their role grants. The Owner account (and any Admin) bypasses the list and can do everything; someone always has the keys. A role with no permissions is effectively read only : that person can look at projects, boards, and documents but cannot change anything. That is a feature, not a limitation: it is the right setup for a customer liaison or an estimator who needs visibility without write access. The built in roles Every new organization starts with a realistic set of shop roles: Admin : everything, including org settings. Shop Foreman : everything, including org settings. Project Manager : runs jobs end to end (projects, tasks, inventory, documents, customers) without org settings. Lead Welder : creates and edits tasks, logs and edits time. QC Inspector : creates and edits tasks, logs time, creates documents (inspection records). CNC Operator : creates tasks and logs time. Fitter : creates tasks and logs time. Two details worth noticing. The edit task permission is the gate on moving work: advancing part stages, editing tasks, and signing QC all require it, so stage data only changes at the hands of people trusted to change it. And QC Inspectors can create documents, because inspection paperwork is documents. Custom roles The built ins are a starting point, not a straitjacket. From the Team page's Roles & Permissions tab you can create your own roles with any combination of permissions: a "Paint Shop" role that only logs time, a "Detailing" role that manages documents but never touches the floor, whatever matches how your shop actually runs. Shift presets let you tag roles by shift for scheduling clarity. Member creation pulls its role options live from your org's role list, so a custom role is immediately assignable. Inviting people Invites are sent from the Team page by email. Each invite carries a secure one time link scoped to your organization and the role you chose; the recipient sets up their account and lands directly in your org. Seats are governed by your plan: the Free plan includes one member, Pro covers a full crew. QC sign offs are attributed, always One permission rule is worth calling out on its own: a QC sign off is recorded under the account that performed it. There is no way to sign an inspection as someone else: the signature comes from the login, with a timestamp. When a customer or an auditor asks who passed a weld, the answer is a person, not a shared terminal. Practical advice Start with the built ins and resist creating roles until a real situation demands one. The most common mistake is granting edit task too widely "to keep things easy"; the whole value of derived status is that stage changes are deliberate. Give the floor the ability to advance their own work, keep delete permissions with the office, and let read only do more work than you would expect.