Invite users and assign roles
Rinvy is a team app — counting, prepping, receiving, and ordering usually involve several people. Inviting teammates and assigning the right role keeps everyone productive while limiting what each person can change.
The four roles
| Role | Can do |
|---|---|
| Owner | Everything. Manage billing, invite users, change permissions, edit any history, delete data. One restaurant can have multiple owners. |
| Manager | Day-to-day operations and overrides — counts, receipts, recipes, prep, orders, reports. Can edit historical counts and receipts. Cannot invite users (Owner only). |
| Staff | Operational work — record counts, receive deliveries, log prep, log waste. Edit their own recent counts within 24 hours. Read access to most of the rest. |
| Viewer | Read-only. See current inventory, history, reports. Cannot record or edit anything. |
Pick the least permissive role that lets someone do their job. You can always upgrade later; downgrading is awkward.
Sending an invite
Go to User management.
- Tap Invite user.
- Enter their email and pick a role.
- Submit. Rinvy creates a placeholder user and sends a welcome email via Resend.
The invited person doesn't need to have an account yet. On their first sign-in (Google, Apple, or email), Rinvy matches the email to the placeholder and links the Firebase identity. They land on your restaurant's dashboard automatically.
Resending or canceling
A pending invite (the user hasn't signed in yet) can be:
- Resent — re-triggers the welcome email.
- Canceled — removes the placeholder. Their email becomes invitable again.
Once the user has signed in, they're a full member and "cancel" turns into "remove user."
Changing someone's role
Find the user in User management.
- Tap their current role.
- Pick the new role and confirm.
Role changes take effect immediately. The user might need to refresh to see updated UI.
You cannot downgrade the last owner. Every restaurant needs at least one Owner — Rinvy enforces this at the API layer.
Removing a user
Removing detaches the user from this restaurant. Their historical activity (counts, receipts, prep logs) stays attributed to them in reports — Rinvy doesn't rewrite history. They just can't sign in to this restaurant anymore.
If they belong to other restaurants, those memberships are unaffected.
Multi-restaurant users
A single Rinvy account can belong to multiple restaurants — useful for restaurant groups, consultants, or operators with side businesses. Each user has a role per restaurant (so you can be Owner in your own and Viewer for a friend's). The kitchen switcher in the sidebar lets them flip between memberships.
What invited users see in the welcome email
- Who invited them.
- Restaurant name.
- A direct sign-in link.
- A short note about their role.
It's plain HTML, sent from welcome@rinvy.app. If it lands in spam, ask them to whitelist that domain.
Common mistakes
Inviting the wrong role 'just to be safe'
Default-Staff is fine for most kitchen team members. Default-Manager means they can edit historical counts and override 24-hour limits, which is a lot of trust. Default-Viewer is the right call for stakeholders who just need read access (accountants, district managers).
Removing instead of downgrading
If someone leaves the role but stays at the restaurant (e.g., moves from cook to dishwasher), downgrade their role rather than removing them. Removal forces a new invite if they ever need access again.
Trying to remove the last owner
The API rejects this. Promote someone else to Owner first, then downgrade or remove the original.