Teams & permissions

Books are only trustworthy if you know who can touch them, who did touch them, and that nobody edited the record afterwards. OnGravy layers all three: role-based permissions enforced on the server, maker-checker approvals on consequential actions, and a tamper-evident audit trail underneath. This chapter walks the whole stack, from inviting your first staff member to sealing a period.

Inviting your team

Team management lives at Settings → Team and is owner-only. Invites run over WhatsApp and phone-OTP — no email round-trips, no passwords to provision:

1. Open Settings → Team and invite by phone number + role.
2. The invitee receives a 6-character join code on WhatsApp.
3. They log in with a phone OTP, enter the join code, and land in your business under the role you assigned.

Seats

• Staff occupy seats, which are paid one-time add-ons (₹199 each — see Mobile, offline & billing).
• Seats are transferable: they belong to the business, not to the person.
• Deleting an employee frees the seat — or transfers it directly to their replacement in the same action. You never re-buy a seat because someone left.

Roles

Every team member holds one of ten roles. The role sets their default permissions across the app:

The permission matrix & overrides

Roles are defaults, not straitjackets. Settings → Permissions shows the full role-permission matrix, grouped by module:

• Click a cell to override that permission for the role in your business.
• Double-click an overridden cell to revert it to the default.
• Per-user overrides layer on top — grant or deny an individual something their role does not, without inventing a new role.

Permissions are enforced server-side on every route — not just hidden in the UI. A user without a permission cannot reach the underlying API either.

Approvals & maker-checker

For actions where a second pair of eyes matters, OnGravy has a full approval system, configured in Settings:

• Approval chains & rules — define who approves what, including amount thresholds (small payments flow; large ones route for sign-off).
• Maker-checker on posted entries — editing an already-posted entry never happens silently: the quick-correct modal routes the change through approval before it lands.
• Escalation — a cron escalates approvals that sit unanswered, so requests do not die in someone’s queue.
• Delegations — an approver going on leave hands their queue to someone else for the duration.

AI agents feed this same discipline: every high-stakes agent action queues for human approval — see Automation.

Period locks

Once a period is closed — filed, audited, or simply done — lock it at Settings → Period locks. Locked periods reject new postings and edits, so January does not quietly change in July. Unlocking is itself a deliberate, logged act.

Audit trail & tamper evidence

Three views answer “who did what”:

• /dashboard/audit-logs — the searchable business-wide audit log.
• /dashboard/my-activity — your own actions, digested.
• /dashboard/activity — the live business-wide activity feed.

And two mechanisms make the record tamper-evident, not just present:

• Daily hash-chain anchors (/dashboard/audit-anchors) — each day’s log is hash-chained to the previous day’s, so retroactive edits break the chain visibly.
• Merkle period seals (/dashboard/audit-seal) — seal a closed period with a Merkle root; any later change to sealed data is mathematically detectable.

Session policy (anti-sharing)

Each user may hold one web session and one mobile session at a time. Logging in on a second browser claims the web session from the first. This is deliberate: shared logins destroy the audit trail’s meaning (“who did what” requires that who is one person). If two people need access, give the second person a seat — it is what seats are for.

Gotchas & good to know

• Only the owner sees Settings → Team. An admin asking “where do I invite people?” is hitting the owner-only gate, not a missing feature.
• Invites need WhatsApp on the invitee’s phone — the join code arrives there, and login is phone-OTP.
• Click vs double-click in the matrix: click overrides, double-click reverts to default. An unexpected permission is often a forgotten override — revert rather than hand-rebuilding the default.
• Per-user overrides survive role changes — when someone changes roles, review their individual overrides too.
• “Random logouts” are usually the session policy: one web + one mobile session per user. Someone else logging in with the same account claims the session — the fix is a seat, not a workaround.
• Posted entries are never silently editable. If an edit seems “stuck”, it is likely waiting in the approval queue — that is the maker-checker doing its job.
• Lock periods after filing. The tamper-evidence machinery (anchors, seals) is strongest when combined with period locks — seal what is closed, lock what is sealed.