Property teams do not fit one “staff” permission
A maid may need today’s schedule and a door instruction without guest financials. A gardener may need a gate code for three properties without access to the fourth. A co-host may edit reservations but still be unable to delete accounting records.
i3nb models those distinctions directly. Access is resolved across the feature, the permission level and the relevant listing or host scope, then sensitive actions add their own granular checks.
Role defaults
Start co-hosts, maids, gardeners and other team roles from sensible role-configurable defaults rather than a blank permission wall.
Listing scope
Authorize a person for selected properties and keep listing-specific screens and actions bounded to those properties.
Host scope
Manage broader abilities such as team administration, shared catalogs, templates and host-wide work separately from listing access.
Sensitive subpermissions
Guest contact, door and confirmation data, financials, deletion and other high-impact actions do not hide behind one general view/edit switch.
A four-part answer to every access decision
Permissions are evaluated as a grid rather than a single role label. That lets two people with the same job title serve different portfolios safely.
Who are they?
The team relationship and accepted role establish the starting policy; a stale or unaccepted invitation does not grant access.
Which feature?
Calendar, reservations, tasks, evaluations, photos, property accounts, work orders and listing settings are independent capabilities.
What level or action?
View and edit are distinct, with granular controls for actions such as delete, approve, complete, cancel or create an invoice.
Which scope?
A grant can apply to one listing, a permitted listing set or an appropriate host-wide resource.
Sensitive reservation data is redacted at the source
It is not enough to hide a button in one screen. Reservation visibility is resolved centrally so different calendar and task views receive the same permitted version of the data.
Guest identity.
Name visibility can be allowed without automatically revealing every other field attached to the reservation.
Contact and access.
Phone, email, door/access information and confirmation identifiers carry narrower permission checks.
Financial details.
Reservation values and property-account screens remain separately protected from operational schedule access.
Destructive actions.
Deleting reservations or transactions and other high-security changes require explicit authority.
Permissions follow the work across the product
The same model governs the day-to-day surfaces where accidental disclosure usually occurs.
Calendar and schedules.
A person can see assigned work or an authorized listing without automatically seeing the full host portfolio.
Property access details.
Wi-Fi, check-in, smart-lock and location details can be granted to the roles that need them.
Accounting and work orders.
Settings, transactions, invoice creation, completion and cancellation have independently enforceable boundaries.
Team administration.
Managing people, listing authorizations and role policy is kept apart from simply being a team member.
How it works
- Invite the person into a defined role. The relationship must be accepted before permission grants become effective.
- Choose the property scope. Authorize only the listings the person actually serves.
- Refine feature and action access. Adjust view, edit and sensitive subpermissions from the role defaults.
- Let every screen resolve the same policy. Calendars, reservations, tasks, accounts and property details use the unified permission model.
Questions
Can a team member work on only selected properties?
Yes. Listing authorization is part of the access decision, so a role can operate across an approved property set without receiving host-wide portfolio access.
Can someone see a reservation without seeing guest contact or financial data?
Yes. Reservation visibility has separate sensitive permissions for guest identity, contact/access details, confirmation information and financials.
Does an old invitation keep granting access?
No. The active team relationship must be accepted. Stale permission rows alone do not establish authority.