Feature toggles — what turning a feature off actually does

Feature toggles — what turning a feature off actually does

Every capability in Stayant is behind a feature toggle. This article is for Stayant admins deciding whether to flip one, and it exists because "off" now has consequences that reach further than the app screen you're looking at.

Read it before disabling anything for a live customer. Several toggles have a knock-on effect you can't see from the admin page.

Where toggles are set

Toggles are set in two places on the admin Subscriptions page, and this part hasn't changed.

Per package — the Packages tab, then edit a package. The Features section lists every feature grouped by area, each with a checkbox (and a numeric allowance where the feature supports one). Every tenant on that package inherits whatever you set here. All on / All off links let you flip a whole group at once.

Per tenant — the Subscriptions tab, then the Features button on a tenant's row. Each feature becomes a three-way dropdown:

• Inherit — take the package's value. The dropdown shows what that currently resolves to, e.g. Inherit (ON).
• Override: ON — force it on for this tenant regardless of the package.
• Override: OFF — force it off for this tenant regardless of the package.

Click Save to apply, or Reset all overrides to drop every override and put the tenant back on pure package inheritance.

An override always beats the package. Editing a package fans its change out to every tenant on it who hasn't overridden that feature.

What changed: "off" now means off everywhere

Feature toggles used to bite only where a user was clicking — menu entries disappeared and the matching API calls were refused. Everything that ran in the background carried on regardless. You could turn a customer's channel manager off and it would keep pushing availability to the OTAs all night.

That gap is closed. A disabled feature now also stops the background work behind it:

• guest email and SMS dispatch
• scheduled messages and review requests
• Channex sync, availability pushes and the nightly rate/availability run
• iCal imports
• automatic charging of saved cards
• payment-schedule reminder emails
• automatic operational-task generation
• custom-domain verification
• public-site analytics roll-ups

Two consequences worth knowing:

Queued work is discarded, not held. Anything already sitting in a queue for a tenant when you disable their feature is marked as suppressed with a reason, and never retried. Turning the feature back on does not flush it out later — those messages are gone. This is deliberate: a week-old "your booking is confirmed" email is worse than no email.

Data cleanup keeps running. Retention and deletion jobs are not gated by feature toggles. A tenant with Analytics disabled still has their expired analytics rows deleted on schedule — withholding a deletion is a data-protection problem, not a feature.

Email is two toggles, not one

This is the one that most often surprises people.

Send Email covers discretionary communication — mail the tenant chose to send:

• manual messages a staff member types and sends
• scheduled messages triggered off booking events
• review-request emails

Transactional Email covers guest-critical mail — mail a guest is waiting on:

• booking confirmations
• booking-change notifications
• payment links
• invoices and payment-schedule reminders

Turning Send Email off does not stop a guest receiving their confirmation, and does not stop them paying their balance. If you want to stop the marketing-flavoured traffic without breaking anyone's stay, Send Email off / Transactional Email on is the combination you want. Turning Transactional Email off is a much bigger hammer — it means guests stop being told their booking exists and stop receiving links to pay. Reach for it rarely and deliberately.

Transactional email survives a lapsed subscription

When a subscription is Awaiting payment, Past due or Cancelled, plan features lock — they switch off as though they were never in the plan (see What your plan includes). Transactional Email is the single exception: it stays on.

That asymmetry is on purpose, not an oversight. A tenant whose payment failed still has guests mid-stay holding unpaid balances. Cutting the payment links out of those guests' emails punishes the guest, who has done nothing wrong, and leaves them stranded with no way to settle what they owe. Withhold the sellable messaging feature; don't withhold a guest's ability to pay money already owed.

Stayant's own emails are never affected

Some mail belongs to Stayant, not to the tenant. None of it is touched by any tenant feature toggle, in any subscription state:

• password resets
• email-address verification
• team invitations
• welcome emails
• contact-form submissions

A customer can never lose the ability to reset their password by losing a messaging feature.

Disabling Channex does not remove the property from Channex

Turning Channex (Channel Mgr) off does three things, in this order:

1. Any queued outbound messages for that tenant are suppressed.
2. A final stop-sell is pushed across every linked property, so the OTAs stop selling the tenant's inventory.
3. Outbound sync then goes quiet — no more availability, rate or restriction pushes.

What it does not do is remove anything from Channex. The property, room and rate-plan listings still exist on the Channex side, and the mapping between them and Stayant is still intact. The tenant is still a Channex property; it simply has zero availability and nothing keeping it current.

To actually remove a tenant from Channex there is a separate, deliberate Deprovision from Channex action. You will find it in Subscriptions → Features for that tenant, in the warning shown below. It asks you to type the tenant's name to confirm, because it is destructive and slow to reverse — re-listing a property on the OTAs is not a one-click undo. It is never triggered automatically by disabling the feature.

If you disable Channex for a tenant who still has live listings, the Features panel warns you: "Channel manager is disabled but this tenant still has N properties listed on Channex. Availability is no longer syncing." — with the deprovision action alongside it. Treat "disabled" and "still listed on the OTAs" as two separate states.

Deprovisioning queues the removals onto the channel-manager outbox, which sends them on its next run, so the listings disappear shortly after you confirm rather than instantly.

Re-enabling queues a full re-sync so Channex receives the tenant's current availability, rather than replaying a stale backlog.

Inbound bookings keep arriving after you disable Channex — on purpose

A stop-sell is not instant. It takes time to propagate out through Channex to each OTA, and OTAs cache. A booking can be sold in that window, after you flipped the switch.

Stayant still accepts those bookings. They are recorded as normal for the disabled tenant.

That is the correct trade. A booking sold in the propagation window belongs to a real guest, who has a confirmation email from the OTA and who will turn up on the date. Accepting it means a tenant briefly gets a booking through a channel they're not paying for — recoverable, and a billing conversation. Rejecting it means a guest arrives at a property with no reservation — not recoverable.

So after disabling Channex, expect a short tail of inbound bookings. If you need inbound to genuinely stop, deprovision.

Disabling the website also disables the embeddable booking widget

This is the non-obvious one. Call it out to the customer before you flip it.

Turning Public Website Builder off takes down the tenant's public marketing site — as expected. But the embeddable booking widget, which a tenant may have installed on a completely separate site of their own, gets its availability and pricing from that same public site. Turn the website off and the widget stops returning results everywhere it is embedded — the tenant's own WordPress site, a partner's site, a landing page, anywhere.

There is no separate toggle for the widget. "No website" means "no online booking", including through the widget. If a tenant has the widget deployed somewhere you don't know about, disabling the website will silently break their bookings on that page.

What still works when the website is off

The public marketing site and its booking flow return "not found" — the same response an outside visitor would get for a domain that was never configured, so a disabled site is indistinguishable from an unconfigured one.

Everything a guest needs after they've booked keeps working:

• guest portal links — a guest can still open their booking
• guest payment and invoice pages — a guest can still pay a balance and download an invoice
• published guidebooks — including the printed QR codes on display at a property
• staff draft-preview links

These surfaces are reached by a token in the link rather than by the tenant's hostname, so the website gate never touches them. That matters because bookings also arrive via Channex, iCal and direct entry: a guest holding one must still be able to view and pay it after the tenant's site goes dark.

What each toggle switches off

Toggle	What turning it off stops
Booking Restrictions	Minimum-nights rules, blocks and channel restrictions.
Task Management	The tasks area, and automatic generation of operational tasks from bookings.
Send Email	Manual messages, scheduled-message emails and review-request emails. Not confirmations or payment links.
Send SMS	Outbound SMS dispatch.
Message Templates	Authoring and reusing message templates.
Scheduled Messages	The scheduled-message engine that fires messages off booking events.
Transactional Email	Booking confirmations, booking-change notices, payment links, invoices and payment-schedule reminders. Stays on through a lapsed subscription.
Stripe	Card payments via Stripe, including automatic charging of saved cards on a payment schedule.
PayPal	PayPal as a guest payment option.
Apple Pay	Apple Pay (which runs through Stripe).
Bank Transfer	Manual bank-transfer reconciliation and bank transfer as a guest payment option.
Channex (Channel Mgr)	Outbound OTA sync, after a final stop-sell. Does not remove the listing, and does not reject inbound bookings — see above.
iCal Import	Scheduled import of external iCal calendars.
iCal Export	The outgoing iCal feeds other systems subscribe to.
Charges & Charge Types	Per-booking charges and charge-type defaults.
Extras	Sellable add-ons on a booking, including guest-facing online extras.
Public Website Builder	The public site, online booking, custom-domain verification — and the embeddable widget. Guest portal, payment pages and guidebooks stay live.
AI Website Assistant	The conversational assistant that designs and edits the public website. Carries a monthly allowance of AI actions.
Guest Reviews	Collecting, displaying and responding to reviews, and the automatic review-request emails.
Property Guidebooks	Authoring and publishing guest guidebooks.
Guest Portal	The online guest portal for confirmations and payments.
Public-Site Analytics	Pageview and event roll-ups for the public site. Expiry of old analytics data still runs.

Changes take up to a minute

Entitlements are cached briefly — for up to 60 seconds — on both the background workers and the public site, so a toggle you just saved may not take effect instantly.

Save the change, wait a minute, then re-check. Don't conclude a toggle didn't work because a background job ran once more or the public site served one more page.

Tip: Before disabling a feature for a live customer, ask two questions. Do they have the booking widget embedded anywhere outside Stayant? And do they have properties currently listed on the OTAs? Those are the two cases where the visible effect and the real effect differ most.