What's new?
This release brings a set of OHIP (Opera Cloud) integration enhancements and fixes, alongside our early launch of Evo for CRS, which continues with some customers prior to the full release later in 2026.
Review the OHIP items relevant to your integration setup. If you manage this area, you can perform the updates yourself. Otherwise, please open a case with support for assistance, or for the full OHIP playbook for reference. Several items are configurable per property, so whether and how each one applies depends on your business practices.
If you would like to learn more about these topics or any of our solutions, please reach out to your Customer Success Manager.
OHIP payment token retention on modified bookings
When a reservation originates in the PMS and includes a saved payment token, the integration can now retain that token within the integration layer, even when no payment gateway is configured on the CRS side. If the guest's booking is later modified through the CRS channels, the saved payment details carry forward automatically and the guest is not prompted to re-enter their card information.
📌Note: Configuration required, this behaviour is controlled by a configurable flag and can be enabled per property. "Share Payment Token with PMS" must be enabled for the token to be retained.
OHIP room assignment retention on CRS-originated updates
Previously, when a reservation was updated through the CRS channels (for example, adding a comment or amending guest details), Opera Cloud could clear a pre-assigned room number, even when the "Do Not Move" setting was active at property level. CRS-originated updates now preserve the existing room assignment in the PMS, protecting pre-blocked rooms and VIP assignments from unintended reassignment during routine modifications.
📌Note: No configuration changes are required. This applies to CRS-originated reservation updates for OHIP properties.
OHIP independent payment message re-sync
When a reservation message fails to deliver, it was previously possible to re-send the reservation but not any associated payment or financial transaction (FinTrx) messages. A payment message can now be re-synced independently when the original send failed, so deposit or payment discrepancies can be resolved faster without manual workarounds.
📌Note: A safety check prevents a payment message that was already delivered from being re-synced, so deposit and refund totals in the PMS stay accurate.
No configuration is required. Payment message re-sync is performed by the SHR Integrations support team when an original send has failed.
OHIP reduced API usage on reservation updates
The integration now stores an internal OHIP reservation identifier the first time a booking is received. Previously, each subsequent update to a reservation required an additional API call to look up this identifier before any change could be applied. By caching this value, that lookup call is removed for existing bookings, reducing the number of API calls made against the OHIP platform. For properties on the OHIP integration this lowers API consumption and improves the speed of reservation update processing.
📌Note: No configuration is required. This applies automatically to properties on the OHIP integration.
OHIP group block sync
A group block synchronisation capability is now available for properties using the OHIP integration. During onboarding, or at any point where a re-sync is needed, group block data can be pulled from Opera Cloud into the CRS, so group inventory and allocation data is reflected in the central reservation system without manual re-entry.
📌Note: Sync requests are subject to Oracle's rate limits (a 90-day window, once every 30 minutes), which are governed by the OHIP platform.
Configuration required, available on the "PMS Interface Resync" tab in the PMS Interfaces section of CRS Admin. Set "Sync Type" to "Group". Leaving the group code blank and selecting resync requests all current group blocks from the PMS; entering a specific group code refreshes that single group block.
OHIP bug fix: source code recognition on PMS-originated bookings
A bug has been resolved where the booking source code on a PMS-originated reservation was not being recognised by the CRS. When a reservation was created in Opera Cloud with a source code that had a corresponding mapping in the CRS channel configuration, the CRS displayed the source as 'PMS' rather than applying the mapped source code value. Source codes defined in the channel mapping are now applied to inbound PMS reservations, bringing behaviour in line with what was previously available under the OXI integration.
📌Note: Configuration required, this is a configurable option that must be enabled. Turn on the "Resv In: Update CRS Channel" setting on the PMS setup page.
Evo early adopters for CRS
We are currently onboarding a select group of early adopters to the Evo standard platform for CRS prior to the general release later this year. The initial feature set includes single sign-on and alerts surfacing missing content and interface action items, with co-pilot and additional analytics to follow shortly. Thank you to those already participating. Your feedback directly shapes how we improve the CRS for all users.
Evo standard is also coming to our other solutions soon. If you would like to see where things are heading, we are happy to arrange a walkthrough of the platform, outline the early adopter program, and answer your questions.
How to access this update
Updates are automatically available in the CRS and are scheduled for production deployment in July 2026. No action is required to receive these changes.