No. Calendars, forms, pricing, and the front-end booking widget stay in WP Booking System. SleekView is a back-office reservation grid that reads and edits the same data. If you uninstall SleekView, every reservation, every calendar, and every booking form continues to work exactly as before, with no data left behind and no schema changes to undo.

Yes. Updates go through the plugin's update layer so notifications and webhooks fire. Guest emails, internal alerts, ICS feed refreshes, and any custom hooks you have built on WP Booking System events all behave as they would if you used the native admin to make the change. There is no parallel save path that bypasses the plugin's logic.

Yes. Any custom field collected on the booking form can be exposed as a column. Special requests, guest count, dietary needs, vehicle plate for parking, or any per-property quirk shows up as a sortable, filterable column. For multi-property operations, columns can be scoped per calendar so each property's view shows only the fields its team uses.

Yes. Payment status and totals show alongside the booking row, with the integration's own status labels (paid, pending, refunded, failed) rendered as a status column. Refunds processed through the WooCommerce admin or directly via the Stripe dashboard reflect in the grid the next time it refreshes its read.

Yes. Per-role row scoping limits visibility to assigned calendars. Property management agencies can scope each owner's representative to only their owner's properties, with no risk of cross-contamination on bulk actions or accidental cross-property access. The capability check uses WP Booking System's own permission model, so there is nothing separate to maintain.

Yes. Strings and field labels follow your active language pack. For sites running WPML or Polylang, calendar names and form labels render in the active admin language, and saved views can be shared across languages because they reference the underlying calendar IDs, not their localized labels.

WP Booking System prevents most overlaps at booking time by checking availability before accepting a reservation. For the rare cases where overlaps slip through, like manual admin-side bookings, the grid surfaces them as adjacent rows on the same calendar with conflicting dates, and bulk decline works on a filtered selection.

Deposit and balance fields are stored separately in WP Booking System and surface as their own columns. Operators can filter to bookings where the deposit is paid but the balance is not, which is the exact shape of the daily payment-chasing workflow most rental operations run.