> ## Documentation Index > Fetch the complete documentation index at: https://docs.garmentflow.ai/llms.txt > Use this file to discover all available pages before exploring further. # User management > Add users to your workspace, assign them a role, manage their access, and secure sign-in with two-factor authentication and passkeys. This is the administrator's reference for managing the people on your GarmentFlow workspace — the roles available, what each role can do, how the maker-checker model gates approvals on finance documents, how to invite a user, how to manage existing accounts, and how to keep sign-in secure. ## Roles Every user has exactly one role, set when the invitation is sent and changed at any time from the **Users** list. The role decides which modules the user reaches, what they may create or change, and — on the finance documents that need it — whether they may approve their colleagues' work. GarmentFlow has seven roles. ### Administrator The workspace owner role. An administrator reaches every module the workspace uses, runs every page under **Settings & Config**, manages the user list, and is the only role permitted to run [data import](/admin/importing-master-data), change [FX rates](/admin/fx-rates), and edit the [POM Library](/admin/pom-library). On finance documents the administrator may act as either maker or checker, and may approve a colleague's submission — but never their own (see [Maker-checker approvals](#maker-checker-approvals) below). Administrators set up and run the workspace. Most teams keep this role to a small group. ### Supervisor A read-only senior role for owners, directors, and any stakeholder who needs the full operational picture without editing it. A supervisor opens every module the workspace uses and sees every order, style, quotation, sample, production run, shipment, and finance document — but cannot create, change, approve, or delete anything anywhere. The role is enforced as read-only across every operational module. A supervisor signs in to their own role-tinted dashboard summarising the workspace at a strategic level. ### Sales The customer-facing operational role. A sales user works in **Quotations** and **Orders** — preparing quotations, converting them into orders, and tracking their own deals through delivery — and reaches the supporting modules they need along the way (**Styles**, **Samples & fitting**, **Shipments**). Sales users see only the work they own. The **Orders** list, the **Quotations** list, the sales dashboard, and the shipment list each filter to the sales user's own quotations and orders. An administrator who needs the cross-team view opens the same pages without a filter. A sales user does not reach **Finance**, **Settings**, or **Data Import**. ### Merchandiser The development-and-production operational role. A merchandiser works across **Styles**, **BOM**, **Cost sheet**, **Samples & fitting**, **Product cards**, **Trim submissions**, **Orders**, and **Production**, owning the style from first prototype through bulk production. A merchandiser may create and edit styles, BOMs, cost sheets, samples, and production records, but does not create quotations. A merchandiser does not reach **Finance**, **Settings**, or **Data Import**. ### Finance The day-to-day finance role. A finance user works across the **Finance** module — recording customer receipts, vendor invoices, vendor payments, debit notes, credit notes, statements of account, and the finance reports — and reads the operational modules they need to do that. On the documents that require approval, a finance user is the **maker**: they create and submit a vendor payment or a debit/credit note, then hand it off to a checker. A finance user cannot approve their own submissions, and cannot approve anyone else's. See [Maker-checker approvals](#maker-checker-approvals) below. ### Finance checker The approver role for finance. A finance checker has the same finance access a finance user does, and in addition is permitted to approve or reject the vendor payments and debit/credit notes a finance user submits. A finance checker may also submit their own — but, like every other role, may not approve their own submission. The **Approval worklist** is the finance checker's home page within the **Finance** module. It lists every vendor payment and debit/credit note awaiting approval, excluding the checker's own submissions. ### Read-only A view-only role for any user who needs to follow the work without participating in it — onboarding staff, auditors, observers. A read-only user opens the operational modules and sees the records there, but cannot create, change, or delete anything, and does not reach **Settings & Config** or the approval surfaces. ### What each role reaches at a glance | Role | Operational modules | Finance | Settings & Config | Approve finance documents | | --------------- | ---------------------------------------- | ----------------------------------- | ----------------- | ------------------------- | | Administrator | Read & write | Read & write | Read & write | Yes (not own) | | Supervisor | Read only | Read only | Read only | No | | Sales | Read & write (own quotations and orders) | No | No | No | | Merchandiser | Read & write | No | No | No | | Finance | Read | Read & write (submits for approval) | No | No (submits only) | | Finance checker | Read | Read & write | No | Yes (not own) | | Read-only | Read only | Read only | No | No | Which modules a user actually sees in the sidebar can also depend on the workspace's sidebar configuration. An administrator can hide top-level items a team doesn't use, so **Finance** and other modules may or may not appear in a given workspace's navigation. See [setting up your tenant](/admin/setting-up-your-tenant) for how the sidebar is configured. ## Maker-checker approvals Some finance documents are too consequential to commit on a single person's signature. GarmentFlow enforces a **maker-checker** model — also called dual control or segregation of duties — on those documents: one person prepares and submits the document (the **maker**), a second person approves it (the **checker**), and the same person can never play both parts on the same document. ### What the model gates The maker-checker model is enforced on three finance documents: * **Vendor payments.** A finance user records a payment against a vendor invoice; it sits in **pending approval** until a checker approves it. Only an approved payment reduces the vendor's open balance and posts to the finance ledger. * **Debit notes.** Issued to charge a customer or vendor for something owed back. A debit note is drafted, submitted for approval, and only posts to the customer or vendor account once a checker approves it. * **Credit notes.** Issued to credit a customer or vendor — for a return, a rebate, or a correction. Same lifecycle as the debit note: drafted, submitted, approved. No other GarmentFlow surface — orders, shipments, production records, quotations, master data — uses the maker-checker model. Their own controls (version locks, status transitions) govern them instead. ### Who plays which part | Part | Roles permitted | | ----------------------------- | --------------------------------------- | | Maker (creates and submits) | Finance, Finance checker, Administrator | | Checker (approves or rejects) | Finance checker, Administrator | A finance checker or an administrator may also submit a document of their own — but, on the documents they submitted, they are the maker. They cannot then approve them. ### The segregation-of-duties rule **A submitter can never approve their own submission.** The rule is enforced by the user's identity, not their role. It applies to every role that may approve, including **Administrator**. Reassigning the document to yourself, switching roles, or being the workspace owner does not lift the rule. The intent is the control: a second person sees the document before it commits. ### The approval lifecycle A vendor payment or a debit/credit note moves through a single, deterministic lifecycle: 1. **Draft.** The maker prepares the document. 2. **Pending approval.** The maker submits the document. It is now visible on the **Approval worklist** to every checker — except the submitter themselves. 3. **Approved.** A checker reviews and approves the document. The figures post to the relevant ledger or account. 4. **Rejected.** A checker reviews and rejects the document, with a reason recorded. The document goes back to the maker to correct or discard. A rejected document never posts. The maker and the checker are both recorded on the document, along with the moment of each transition. ### The Approval worklist The checker's home for this work is the **Approval worklist** within the **Finance** module. It lists every vendor payment and every debit and credit note awaiting approval, and lets a checker open, review, approve, or reject each one. A submitter's own pending items are filtered out of their own worklist — they appear on every other eligible checker's worklist instead. ## Inviting a user To add someone to your workspace: 1. Open **Users** from the **Settings & Config** sidebar group. 2. Choose "Invite user" and enter the person's email address, name, and role. 3. They receive an email invitation. Following the link, they set their own password and sign in. You never set a password for a new user — they create their own through the invitation link, so no one else knows it. **If the invitation doesn't arrive.** Ask the invitee to check their spam or junk folder first. If it's still missing, re-send the invitation from the **Users** list. ## Managing existing users From the **Users** list you manage everyone already on the workspace: * **Change a role.** Promote a user to a higher-access role, or step them down, as responsibilities change. The new role applies on their next page load — they do not need to sign out and back in. * **Deactivate a user.** When someone leaves the team, deactivate their account. A deactivated user can no longer sign in, but their history stays intact — the quotations they wrote, the orders they confirmed, the payments they submitted, and every other record they touched remain for audit. Deactivating is the right action when someone leaves; records are never deleted along with the person. A deactivated user's submitted finance documents stay where they are — pending ones remain pending and a checker can still approve or reject them; approved ones keep their original maker and checker on the record. ## Securing sign-in GarmentFlow supports standard email-and-password sign-in, and adds two stronger options on top: * **Two-factor authentication (2FA).** After entering their password, the user confirms a one-time code from an authenticator app. Even if a password leaks, the account stays protected. * **Passkeys.** A passkey lets a user sign in with their device's own biometric or PIN — there's no password to phish or reuse. From the **Users** list, an administrator can see which users have 2FA enabled. We recommend 2FA for everyone, and treat it as mandatory for administrators and finance checkers: an administrator account reaches every setting, and a finance checker can release money. ## A note on the Data Import permission The [Data Import](/admin/importing-master-data) tool is currently administrator-only. If you need someone to run a bulk import, they need an administrator role. A future release may let an administrator delegate the Data Import permission to specific users without granting full administrator access. ## Related pages * [Setting up your tenant](/admin/setting-up-your-tenant) * [Your account](/admin/your-account) * [Audit log](/admin/audit-log) * [Workspace settings](/admin/workspace-settings) * [Feature settings](/admin/feature-settings) * [Importing master data](/admin/importing-master-data)