YStay

Invite your team and set their roles

Two independent axes govern a teammate's access — what they may do, and which properties they may do it on. The invitation form sets both, and the link is handed over only once.

A YStay account can be shared. The Team page, in the Account group of the navigation, welcomes a concierge, a housekeeping crew, an accountant or a co-investor, and sets two independent things for each of them: their permissions (what they may do) and their property scope (where they may do it). Forgetting the second one hands the whole portfolio to someone who only services one studio.

Opening this page with controls does not come from the role but from a permission: the Gestion box on the perm.module.coreTeam row — the technical identifier of the Team module in a member's matrix, see “What the matrix displays” below. A Manager gets it by default, Staff does not; tick it for a Staff member and they will manage the team just as you do, take it away from a Manager — or apply an access preset to them, see below — and they lose it. The owner always has it and is never editable: that role cannot be assigned, and no scope ever applies to them. Inviting new members also requires a plan that includes teamwork — without it the page replaces the form with See plans, while still letting you manage the members already there.

Inviting, screen by screen

  1. Fill in the invitation form

    The Invite a teammate card asks for four things: Email address, Role, Access preset and Accessible properties.

    Role is one of Manager, Staff and Read only: the owner role cannot be assigned. Access preset offers Default (based on role) and then five ready-made presets.

    Screenshot to be produced

    captures/inviter-equipe-regler-roles/01-inviter-membre.png

  2. Choose the property scope

    Under Accessible properties, tick the properties this member should see. Ticking nothing is not an oversight, it is a decision — and the screen spells it out: “No selection: access to all properties.” A property that does not belong to your account is dropped silently: the saved scope only ever contains your own.

  3. Hand the link to the person you invited

    Invite confirms with “Invitation sent. Share the link below to finalize access.”, shows the Invitation link, and the person appears in the list with the Invited badge.

    That link opens a page asking them to sign in — or create an account — with the invited email address, then validates the access. That page is shown in French; its English version comes from adding “?locale=en” at the end of the link.

    On that page, the invited person ticks a box before they can continue: "By joining this account, I have read and accept the individual terms of use in force." The link opens the text; the Join the team button stays inactive until the box is ticked. Those are their terms, not yours: they are not a party to your contract with YStay, and their answer only binds their own access.

    Screenshot to be produced

    captures/inviter-equipe-regler-roles/02-lien-invitation.png

  4. Fine-tune the access afterwards

    On a member's row, Manage access opens their panel: Access template (preset), Permissions by module — one box per module and per action — and Accessible properties. Save access closes the matter.

  5. Read the team matrix back

    Each row recalls the role, the preset if any, and the scope: All properties, or the number of properties selected. The owner never shows a scope at all.

    Screenshot to be produced

    captures/inviter-equipe-regler-roles/03-roles-et-perimetre.png

Field agents, on the same page

Below the Roles card, the Team page carries a second list: Field agents. It does not gather members of your account but outside workers — people without a YStay account, added with a name and a phone number, who work from a link sent by SMS or WhatsApp, and contractors with an account invited by email. How it works is described in Add a field agent without an account; three points are enough here.

  • It does not depend on the Team plan. Even when the page replaces the invitation form with See plans, the Field agents card stays displayed.
  • It has its own module in the matrix: the Field agents row. The Lecture box opens the card; the Écriture box opens Add an agent and each row's actions (edit, resend or revoke a link, suspend, invite to create an account). The Concierge and Manager presets have read and write, the Ménage preset read only.
  • An agent is not a member. They have no role and no access to the dashboard: they only see the tasks assigned to them, from their link.

The three roles, and the five presets

The The roles card at the bottom of the page sums up the base:

  • Owner & Manager — full access: operations, sales & marketing, team and billing.
  • Staff — field operations (reservations, stays, housekeeping, incidents). No team or billing management.
  • Read only — view only, no changes.

Those summaries are the card's own, and the Staff one is narrower than reality: its base opens, for reading and writing alike, the same modules as the Manager preset — Messaging & automations, Short-term finances and Inventory & pricing included —, without team or billing management.

Five presets are on offer — Concierge, Ménage, Compta, Co-investisseur, Manager — plus a fully manual mode: Custom (manual), in a member's panel. A preset does not refine that base, it replaces it: as soon as a preset sits on a member, their permissions come from that preset alone and the role's base is never consulted again. A Manager you apply a preset to therefore loses team and billing management — not one of the five carries them, not even Manager. A Read only role, for its part, stays read-only whatever you tick: the server refuses every write coming from that role.

Each member only receives and sees the notifications of the modules their access opens — unless stated otherwise below, those whose Lecture box is ticked. The rule is the same on the field app (the phone notifications) and in the dashboard bell (the Notifications panel). The account owner receives them all; a member removed from the team no longer receives any. In the bell, the access required is:

  • Messaging & automations (row perm.module.stayMessaging) — a new guest message, a guest request forwarded by support (“A request has been forwarded to you”).
  • Stay operations (reservations, check-in/out) (row perm.module.stayOps) — a confirmed reservation, a new guest review, the reminder to rate your guest, a new incident, a guest inspection completed or awaiting co-validation, the notice that StayProof evidence is about to be purged.
  • Short-term finances (row perm.module.stayFinance) — a cancellation refund to finalize, a deposit to release manually, a support action awaiting your confirmation (deposit release).
  • Inventory & pricing (row perm.module.stayInventory) — the alerts from your channels: sync failure, updates rejected by a channel, listing still on sale, relisting not applied, taken-over listing kept, channel reservation not matched, reservation change to arbitrate.
  • Stay operations or Housekeeping & turnovers (row perm.module.stayHousekeeping), either one is enough — the Terrain alerts: task not started, blocked, not seen the day before, proof missing. The bell shows them for the whole account, not only for your own tasks.
  • Subscription & integrations (row perm.module.coreBilling) — the trial ending soon and the trial ended, for those who manage the subscription: the only box on this row is Gestion, which a Manager has by default and Staff does not.
  • The whole team, whatever their access — the YStay support reply to a request from the account (“Reply to your support request”), whose title is neutral.

A member limited to certain properties also sees, in the bell, no entry for a property outside their scope. Some notifications exist only on the phone, with no entry in the bell: the overdue payment installment, for example, only notifies members who have Short-term finances (perm.module.stayFinance).

What each access opens in short-term rentals

The server applies the matrix to every screen and every gesture of short-term operations and of their catalogue (listings, rates, guidebooks, site, partners, contracts): what a member is not allowed to do is not merely hidden from the menu and from the app, it is refused — and the direct address of a closed screen shows Access denied. In each module, the Lecture box opens what can be viewed and the Écriture box what can be changed; the two are independent, and the account owner has every box.

  • Stay operations (reservations, check-in/out) — row perm.module.stayOps.
    • Lecture: guest reviews (the Guest reviews page and the Guest reviews section of the reservation page — guest name and private feedback included), reservations and the panels of their page, insurance certificates, generated contracts (the Generated contracts tab of the Seasonal contracts page: list, detail and PDFs), today's board (Arrivals, Departures, Current stays), stays, incidents and their dossiers, the state of the access codes — never the code itself —, check-in/out sessions, inspections and their comparisons, locks, TV screens (the Devices page), inspection templates, the incentive policy, the full StayProof evidence export (Download the full file (ZIP)), reservations in search (⌘K) and the guest's name on the calendar, in channel conflicts, when stopping sales and when withdrawing a listing.
    • Écriture: reply to a guest review (the reply is posted on the original platform in the account's name) and hide a review; create, edit or cancel a reservation; declare an incident and move it along; View code, issue and revoke a door code; attach, edit, test and detach a lock; add, rename and remove a TV screen, send it a command and set what the unit's screens display; close or reopen nights on the calendar, set or lift a blocked period and edit a guidebook — gestures the Écriture box of Inventory & pricing also opens; open and close a session; run an inspection; set up inspection templates and the who-performs-it policy; issue, remind and revoke the guest inspection link — and read its address; read the address of the guest payment link; Regenerate, Resend link and Cancel contract on a generated contract.
  • Messaging & automations — row perm.module.stayMessaging.
    • Lecture: read conversations and the automated messages sent for a reservation — a door code those messages contain stays masked there, see below.
    • Écriture: send a message, ask the AI for a draft, create and edit automations and message templates.
  • Short-term finances — row perm.module.stayFinance.
    • Lecture: a reservation's amounts, installments and payments, and the partner statements (the Partners menu also opens to this reading).
    • Écriture: charge, refund, hold or release a deposit, approve or reject a claim, change the inspection incentive policy (Inspection incentive card), and — like Inventory & pricing — freeze a partner statement, add an adjustment to it, issue or revoke the merchant link.
  • Inventory & pricing — row perm.module.stayInventory.
    • Lecture: the Calendar, like Stay operations (opening a reservation's page from the calendar stays reserved to Stay operations, and so does the guest's name — see below); the Pricing, Contracts — without its Generated contracts tab —, Guidebooks and My site menus; the Partners menu, which the reading of Short-term finances also opens, for the statements. The pages of properties, units and listings — photos, amenities and rates included — need no box: every member reads them, and a member limited to certain properties only sees their own.
    • Écriture: properties, units and listings (title, description, publication, amenities, translations, stopping sales), their photos and zones, rates (base rate, seasons, fees, extras), prices set on the calendar, stay restrictions, PriceLabs, channels (iCal address included), the site and its domains, partners (records, inserts, placements, attribution QR codes) and contract templates with their per-property overrides. Three neighbouring openings: the guidebook (content, photos, languages, publication) also opens to the Écriture box of Stay operations; so does closing or reopening nights on the calendar and setting or lifting a blocked period — but sending a price requires the Écriture box of Inventory & pricing; partner statements, their adjustments and the merchant link also open to the Écriture box of Short-term finances.
  • Housekeeping & turnovers — row perm.module.stayHousekeeping.
    • Lecture: cleaning and welcome tasks, their checklist, their photo proofs and My day on Host Ops.
    • Écriture: move them along (start, finish, block, assign, add a proof) and create a task. Stay operations opens the same tasks; this module, for its part, opens neither reservations, nor today's board, nor codes, nor sessions, nor inspections.

Three pieces of information follow a finer rule than “read” and “write”, because they identify the guest or open the door:

  • The guest's name, wherever it only serves to spot a reservation. Without the Lecture box of Stay operations — with only the reading of Inventory & pricing, for instance —, the calendar shows Reservation in place of the name (Timeline bar, Month view pill, side panel header), channel conflicts show Guest, and stopping sales or withdrawing a listing list the kept reservations by their period alone. The rest — dates, status, channel, reference — is not removed: it is enough to settle a calendar conflict. Messaging and Earnings keep the name, which they need to reply and to match a payment.
  • A door code in an automated message. When an automation contains the Access code token, the guest receives the real code. On the host side, the conversation and the preview in the conversation list replace it with •••• for anyone without the Écriture box of Stay operations — a member who only has Messaging & automations, the Read only role — and for the YStay team when it works on your account. The owner and the accesses that have that write box — the Concierge and Manager presets, the Manager and Staff roles as long as no preset is applied — read it in the clear.
  • The address of a guest link. The payment link of the guest space and the inspection link both open the guest's journey in their place: their address is only shown to members who have the Écriture box of Stay operations. The others only read that a link exists — “A guest payment link is active.” on the Guest space card of the Contract & documents panel of a reservation's page and in the Extras panel, “A guest link is active.” in the Guest link block of the Guest inventory panel —, followed by “Its address is only shown to members with write access to "Stay operations (reservations, check-in/out)".” The YStay team never sees these addresses and issues neither door codes nor guest links.

The same goes for the makeup of the team: when the YStay team works on your account, it can neither invite a member nor change the access of a member already on the team — their role, Access template, Permissions by module, Accessible properties. Those actions stay yours; it can, however, remove a member, as an emergency measure — with the effects described in “What leaves with a member”, and that removal also disables the OAuth applications that member created.

The same goes for third-party access: it neither creates, deletes nor authorizes an OAuth application on your behalf — not on the API & integrations page, nor when an external tool asks for access to your account. Nor does it connect, replace or remove your lock provider's token: on the Connected locks card, Connect, Update token and Disconnect are refused to it. It can, however, cut the access of an application that is already connected, but from its own console, with a reason recorded in your account's audit log — never by signing in in your place. On a listing's Connected lock card, it does not attach, edit or detach a lock either; it can still Test it, without that test changing the status of your connection.

The catalogue — listings, rates, guidebooks, site, partners, contracts — adds three rules to “read” and “write”:

  • A member limited to certain properties. Even with the Écriture box, they only edit the listings, photos and zones, guidebooks, rates and contract overrides of their properties, and the lists of units and listings, like the media library, only show them their own properties. The settings that apply to the whole account stay closed to them for writing: the site and its domains, partners, contract templates, custom amenities, the PriceLabs account. They can read them, and the screen says “This setting applies to the whole account: it is reserved for members whose access is not limited to specific properties.”
  • The landlord signature (the Landlord signature tab of the Seasonal contracts page) depends on no box: only the account owner saves, replaces or removes it, and neither the Manager role nor the Manager preset can. Other members read “Only the account owner can save, replace or remove their signature.” instead.
  • The YStay team, when it works on your account, does not do on your behalf the gestures that commit your shop window, your contract text or your public links: neither publishing nor unpublishing a site or a guidebook, nor deleting a site, nor changing its Address (slug), Contact email or Contact phone, nor managing your domains (adding, verifying, primary domain, deleting), nor publishing or archiving a contract template, nor saving an override in the Per-property overrides tab, nor touching your signature, nor issuing a public link — a statement's merchant link, a placement's attribution link —, nor reading a channel's iCal address, nor sending a full-screen Message to a TV, nor reminding a guest about their inspection. It can, however, display the QR code of an attribution link you have already issued, to help you print it again.

What that gives for each access preset:

  • Concierge — Stay operations, Messaging & automations and Housekeeping & turnovers and Early check-in and late check-out for reading and writing, Inventory & pricing for reading; no Short-term finances. On the catalogue side, its writing on Stay operations leaves it the whole guidebook, closing and reopening nights on the calendar, blocked periods and TV screens; it edits neither listings — description, photos and zones, publication —, nor prices, extras and fees, nor the site, nor partners, nor contracts.
  • Ménage — Housekeeping & turnovers for reading and writing, plus Stay plans and Field agents for reading, and nothing else: no reservations, no today's board, no codes, no sessions, no inspections, no evidence export.
  • Compta — Short-term finances for reading and writing, Stay operations for reading: it reads reservations, incidents, stays and the evidence export, without ever seeing a door code. It also handles partner statements — reading them, freezing one, adding an adjustment to it, issuing the merchant link — without editing partners, inserts or placements.
  • Co-investisseur — Stay operations and Short-term finances for reading only, partner statements included.
  • Manager — every module for reading and writing, except team and billing management.
  • Custom (manual) — no box at the start: nothing is open until you tick it.

The inherited Read only role views everything the Lecture boxes open, but writes nothing: it therefore never sees a door code. It can, however, download the full StayProof evidence file — preparing that archive is a read, which changes nothing in your account.

What a Read only role sees

The Team page opens, but without a single control: no invitation form, no role selector, no Manage access. The banner names the role — “Your role (Read only) does not allow managing the team.” — but what is missing is the permission: a Staff member sees exactly the same screen, and that same Staff member gets the controls back the moment Gestion is ticked on perm.module.coreTeam. The navigation narrows at the same time: Subscription, Payments and API & integrations disappear, for want of the right to manage billing; Earnings and Insights remain reachable, for viewing — as long as no access preset has been applied to that member, since a preset recomputes what they see too.

What leaves with a member

A member may have plugged tools from other publishers into your account: the authorizations they gave appear in the Connected applications card of the API & integrations page. They do not outlive the member; they are cut when:

  • you remove them from the team, with Remove;
  • you reduce their rights below “every right on every property” — a narrower role, an access template that does not open everything, or a scope limited to certain properties — with Save access;
  • you re-invite them, which puts them back to the Invited status;
  • their user account is erased from YStay.

In each case, the third-party applications they had authorized lose their access to your account. Each cut is recorded in your account's audit log. When one of those applications then tries to renew its access, its request is refused; it learns nothing about your team.

What the account owner connected is never touched, nor is what another member connected. A change that leaves the member with every right on every property cuts none of their authorizations. The details of the card, of the Revoke access action and of the lifetimes are in Set up your account and integrations.

The applications the member created themselves on the API & integrations page go in the same cases, but they are disabled for good: see the callout “Reducing a member's access disables the OAuth applications they created” above.

Requiring two-step verification from the team

At the very bottom of the page, Team security carries a switch: Require two-step verification for the team. The confirmation is blunt — “EVERY team member, including you, stays locked out until they turn on two-step verification.” Hence the guard: if your own second factor is not on, YStay refuses — “Turn on your own two-step verification before requiring it from the team.” — and offers Go to my security settings. Lifting the requirement, by contrast, has no condition at all.

Next

Updated on