Admin Users

This standard governs administrative access to the Platform: who holds an account, what role they hold, which modules that role opens, and how access is granted, suspended, and reviewed. Access control here is role first, then module by module: the operator selects the role on the Users screen, and the screen presents the editor that matches that kind of relationship to the business. Hand-tuning grants before choosing the right role produces an illegible access position. Only an owner, or an administrator holding the administration grant at the highest level, may create accounts, change roles, or change grants; every such change is recorded with the person who made it, the earlier value, and the new value. No access setting in this standard overrides a governing legal document, an employment decision, or a franchise agreement.

The eight roles

The roster recognizes eight role types. Each is a different kind of relationship to the business, and each receives a different editor

1. Owner: passes every check. Presented as a simple control. There shall be very few owners; every owner is a person who can undo anything, including another operator's restrictions.
2. Internal employee: the Company's staff. Receives the module tree described below: every module at None, Read, Write, or All. This is the role used most.
3. Franchise owner: full administration, limited to their own tenant. Receives a tenant selector, or the new-franchise flow in Franchise Signup. They run their shop; they do not touch the Company's.
4. Franchise employee: the module tree again, limited to franchise-scoped modules.
5. Seller: category selections, Pro standing, and capabilities. Marketplace Sellers, not staff, governed additionally by the Selling Terms of Service.
6. Veterinarian: action controls plus a licence profile, for telehealth providers.
7. Pharmacy: action controls, a licence profile, and an acknowledgment concerning protected health information. That acknowledgment is not decoration; it records that this role touches prescription handling.
8. Groomer partner: lead modules and lead actions only. Referral partners, not employees.

Customers hold no rows on this roster. That is deliberate: customers have a uniform experience, and there is nothing to configure per customer on the access side.

The roster shows, for each person, a count of the explicit grants they hold beyond their role. Where that count is high for someone whose job is simple, that is the cue to review. Grants accumulate; nobody removes them unprompted, which is why the review cadence below exists.

The module tree

Modules are the coarse control. Five are in use

1. Accounting: settings, reports, taxes, payroll, books, invoices, payments, deposits, refunds, gift cards, and the processor connection, governed by Accounting of this library.
2. Customer management: the dashboard, customers, pets, appointments, grooming records, calendar, services, staff, and schedule.
3. Orders: inventory, orders, purchase orders, returns, and shipping.
4. System: settings, governed by Settings and System.
5. Support: reply, approve actions, delete, export, merge, view, confidential material, internal notes, macros, administration, and copyright-removal handling.

Each module is granted at one of four levels: None, Read, Write, or All. The matrix is designed around least privilege, kept legible

1. Owners hold everything.
2. Managers hold their department's modules at All.
3. Front-desk staff hold customer appointments and customers at Write, but not refunds or settings.
4. Accountants hold Accounting, but not staff management.

When a person changes jobs, their grants are updated the same day. Stale permissions are the most common source of "how did they do that," and they are entirely preventable. Every permission change is recorded in the permission audit record with the earlier and new values, who made the change, and when. That record answers "who gave the new hire refund permission" and allows a bad grant to be unwound without guessing.

Invitations and lifecycle

Nobody receives a sign-in directly. Access begins with an invitation

1. The administrator creates the membership record and sends the invitation. Until the invitation is accepted, the person has nothing, whatever the role says.
2. The record carries who sent the invitation, when it was sent, and when it expires. Invitations expire on purpose; an invitation months old in an inbox is a standing vulnerability.
3. The invitation link is stored only as a protected reference, never in readable form. A database read cannot reconstruct a working link. Where someone asks an operator to simply state the link, the honest answer is that the operator cannot: the administrator resends, and the system issues a fresh link, leaving the old one dead.

The pending-invitation list is worked as a queue, not read as a report. Every pending invitation is a person who cannot yet do their job

1. Expired: resend. The old link stays dead; that is the secure behaviour.
2. Never arrived: check the sent time first; the cause is almost always a mail filter or a mistyped address. Correct the address, then resend.

The last-active time on each membership is the access-review tool. Quarterly, the administrator sorts by it: anyone inactive for ninety days probably should not hold an active role. Access nobody uses is access nobody will notice being misused.

One person holds one membership record. Where someone needs a different role, the administrator changes the role on the existing record; a second record is never created. Duplicates are how a person ends up suspended in one record and fully active in another.

Suspending and deactivating

Suspension is the emergency brake: the membership is made inactive, and, for scheduling and register access, the staff record is made inactive with it. History is preserved: appointments the person handled, notes they wrote, audit entries. The past is not rewritten when someone leaves.

1. Suspend first, investigate second, decide third. In a termination conversation, suspension happens during it, not after. Where misuse is suspected, suspend, then read the audit records; a person under investigation with live access does more damage in an hour than the investigation takes.
2. Suspension does not reassign open work. Appointments under a suspended groomer still show that groomer until someone moves them; open register sessions, pending approvals, and assigned conversations sit where they were. After suspending, the administrator walks the person's active responsibilities and reassigns each one. The Platform preserves the data; the handoff is the administrator's.
3. Reactivation restores the record as it was: history, permissions, and settings intact. That is the advantage over deletion: a pause, not an ending. Deletion is reserved for the rare case it truly fits, and even then the deactivated record is preferred. The audit history is worth more than tidiness.

Two-factor authentication resets

A reset is the recovery path where a person loses the device their second factor lives on, and it is two steps by design: an administrator records the request: who requested it and which administrator recorded it: and the user enrols afresh at the next sign-in. A reset is never silent; there is always a record of who asked and who approved.

1. Verify identity before approving. "I am locked out, please reset my authentication" is exactly what an attacker says too. The administrator calls back on a known number or confirms in person. Thirty seconds of awkwardness is the entire security of this procedure.
2. After a reset, the old device is fully detached; the new enrolment replaces it.
3. Repeated resets for the same person are a signal, not a routine. The administrator establishes which it is: a chaotic device situation, or someone testing the procedure.

What the Users screen enforces

Every read and write on the Users screen passes through the administration gate: the person operating the screen needs the administration module at the right level. Where the screen loads empty or saves fail, the cause is usually the gate, not the data. The permission model applies to its own administration: an operator needs permission to grant permission.

Controls

• Who may change access. Owners, and administrators holding the administration grant at the highest level. Nobody grants a module they do not themselves hold at the level granted, and nobody approves their own grant increase.
• Access is granted by role and least-privilege module levels, reviewed quarterly against last-active times and grant counts.
• Payroll-related access is additionally limited under Payroll: payroll records are confidential, and an Accounting grant is narrowed for payroll to the roles that standard names.
• Banking and processor credentials are never created, shared, or reset through this screen, and are never recorded in any document; see Banking.
• Suspension takes effect immediately and is never delayed for convenience; reactivation requires the same authority that suspension does.

Records created and where they are kept

Membership and roster records, invitation records with their send and expiry times, the permission audit record for every grant change, suspension and reactivation records, and authentication-reset requests are kept in the Platform's administrative records and retained under the Regulatory Record Retention Policy.

Escalation

Suspected misuse of access, a grant nobody can account for, or a reset request that fails identity verification goes to an owner the same day; suspected compromise of an account and any legal process touching access records go to legal@aapawz.com. Operational failures of the Users screen go to support@aapawz.com, after the gate check above and the checks in Troubleshooting (Organization Settings Troubleshooting).

Review cadence

Access is reviewed quarterly: last-active times, grant counts beyond role, pending invitations, and owner accounts. This standard is reviewed whenever a role or module is added or its scope changes.