Team & RBAC

A property owner rarely runs check-ins themselves. They hire a front-desk team, a manager, possibly an accountant. ABc lets the owner add as many staff accounts as they need, each with a scoped role that limits exactly what they can see and do.

Built-in roles

Permission matrix

Every action in ABc maps to one of ~30 permissions. Here is the abbreviated map across the 5 preset roles:

Property scope

Beyond role, every team member is scoped to one or more properties. A multi-property owner can hire one manager for "Manali" and another for "Kasol" — they will not see each other's data.

Team list UI

Invite member · UI

Custom role · permissions editor

Activity by member

Invite flow

1. Owner enters email + role + property scope

   Optional: a personalised note.

2. System sends invite email

   One-time link, valid 7 days. New users get a sign-up page; existing users get a one-click accept.

3. Invitee accepts

   If new: completes sign-up (name, password, phone OTP). If existing: just confirms.

4. Membership row created

   user × property × role stored in memberships. User now sees that property in their workspace switcher.

5. Welcome email + notification to owner

   Owner gets a heads-up that the invite was accepted.

Removing a member

• Owner clicks "Remove" → confirmation dialog → membership row deleted.
• Active sessions for that user / property revoked immediately (JWT version bumped).
• The user's bookings and audit entries stay intact (we never delete history). Their attribution is preserved.
• If the user has no other memberships, their account remains but they lose access to this workspace.

The DB model

Permission checks in code

// Express / NestJS-style guard
@RequiresPermission("booking.cancel")
@RequiresProperty()
async cancelBooking(@Param("id") id: string, @User() me: CurrentUser) {
  // Guard already verified:
  //   - user has booking.cancel permission
  //   - user has access to the property the booking belongs to
  return bookings.cancel(id, me);
}