A single OPERA Cloud check-in does not update every hotel system at the same instant. The reservation status change triggers a business event that different interfaces pick up on different timelines — some on a direct command path, some only on a later occupancy signal — and a lock, a guest-room controller, a TV, and a Wi-Fi splash page can each independently drift out of step with the PMS. Testing a single channel in isolation will not catch that; the more reliable opening-day test follows one check-in forward through all four outputs at once. Cave Group's hospitality integration work covers this kind of PMS, lock, guest-room, and network coordination as part of commissioning a property before it opens.
This matters because guest-facing systems are built by different vendors on different integration patterns, and each one treats "checked in" differently — as a reservation attribute, a lock credential, an occupancy signal, or a network session. Below is what the available documentation says about how each system actually receives the event, and where an integrator should put test effort.
What does OPERA Cloud actually send at check-in?
OPERA Cloud's hospitality integration platform (OHIP) exposes reservation changes as business events that a connected partner system can subscribe to under the Reservation module, rather than as a single universal broadcast to every downstream device. Oracle's own documentation describes this pattern for guest messaging: "OPERA Cloud PMS creates a guest message and sends a notification to the external system" using a specific Streaming Event, and the external system is expected to separately post back a status update such as "delivered" (Business Context). The same notify-then-acknowledge shape applies more broadly: a connected system needs its own subscription to the relevant business event and is responsible for acting on it and, where applicable, confirming back to OPERA. A property should confirm with its OHIP integrator exactly which business events each vendor subscribes to, because a missed subscription on one system will not show up as an error anywhere else.
Which system typically reacts first — the lock or the room?
Electronic lock platforms can react through a fairly direct path because key issuance is tied to the check-in transaction itself in at least one documented integration. Salto's integration with the Mews PMS shows this: "When a system operator triggers a new key creation either via the PMS (Mews Web app) or via the Mews Kiosk, a key encoding command is created and the Mews Connector application receives this new command notification" (MEWS | Salto). That is a direct command path from a PMS-triggered action to key creation.
The guest-room system's trigger point, by contrast, is tied to occupancy rather than the PMS transaction in Crestron's own documentation: "As guests enter their room sensors trigger automated, personalized scenes... Presence detection sensors verify occupancy and automatically reports it to the Guest Room Management System (GRMS)" (Hospitality Guest Rooms). In other words, check-in can authorize a key, but the welcome lighting, shade, and climate scene is described there as waiting for the guest to physically open the door — a second, independent event a test plan has to account for separately from the PMS transaction.
A property planning a custom guest-room automation system on Crestron, or a packaged Lutron myRoom deployment, should ask its integrator to document both trigger points in writing: what the PMS check-in event alone changes, and what only occupancy detection changes.
Where do the in-room TV and Wi-Fi portal fit in the sequence?
Guest-facing TV welcome screens and messaging run on the same OHIP guest-message workflow referenced above — a partner system receives a check-in notification, then separately retrieves or receives message content to display on an in-room device, and reports delivery status back to OPERA Cloud. That round trip (notify, display, acknowledge) means a welcome screen or greeting is not guaranteed to appear the instant the front desk clicks check-in; it depends on how quickly the connected system polls or processes the streaming event.
Wi-Fi captive portal behavior is not covered by the fetched OHIP or Crestron documentation, so this is a question to put directly to an integrator and network vendor rather than an assumption to carry into commissioning: does the guest's room-based network credential activate at PMS check-in, or only once a device actually associates to the SSID and authenticates against occupancy data? Confirm this explicitly rather than assuming it mirrors the lock or the room controller.
What should an opening-day test sequence check?
Rather than testing the lock, the room system, the TV, and the network as four separate projects, run one test reservation through all four in sequence and log the timestamp each system reacts:
- Create a check-in in OPERA Cloud and note the time the lock credential becomes valid at the door.
- Physically open the door and confirm the guest-room system's occupancy-triggered welcome scene fires, not just a profile load at check-in.
- Confirm the in-room messaging or TV welcome content appears, then confirm OPERA Cloud receives the delivery acknowledgment back from that system.
- Ask the network vendor to state in writing what the Wi-Fi portal's actual trigger is, then confirm it grants access on that documented trigger rather than an assumed one.
- Repeat with a same-day room change and a check-out to confirm each system clears its state — the lock revokes, the room returns to a setback profile, and the network session ends.
This kind of cross-system acceptance checklist is worth building into any property's commissioning plan before go-live, alongside the broader PMS integration and guest-room automation scope covered on Cave Group's hospitality page.
Frequently asked questions
Does a PMS check-in update the lock, the room, and the TV at the same moment?
Not necessarily. OPERA Cloud's business events reach each connected system through its own subscription and integration pattern, and Crestron's guest-room documentation shows the room's welcome scene is commonly triggered by occupancy detection rather than the check-in transaction itself, so these systems can update at different moments.
What triggers a Salto key after an OPERA or Mews check-in?
In Salto's documented Mews integration, a key encoding command is generated when a staff member or guest triggers key creation through the PMS web app or kiosk, and the lock vendor's connector application receives that command notification directly — a fairly immediate path tied to the PMS action itself.
Does the guest-room lighting and shade scene fire at check-in or when the guest enters?
Crestron's hospitality documentation describes the welcome scene as triggered by presence sensors when the guest enters the room, with occupancy then reported back to the Guest Room Management System — not by the PMS check-in event alone.
How should a property confirm what the Wi-Fi portal uses as its trigger?
The fetched OHIP and Crestron sources do not define Wi-Fi portal trigger behavior, so a property should require its network integrator to document explicitly whether guest network access activates at PMS check-in or at device association, and test both before opening.
Who should own testing this sequence before a hotel opens?
A hospitality technology integrator coordinating PMS, lock, guest-room, and network vendors should run a single test reservation through all four systems together rather than testing each vendor in isolation, since isolated testing can miss timing gaps between systems.