This article covers Opera Cloud-specific behaviours that can affect how FLYR pushes price and restriction updates. Understanding these will help ensure your optimization setup works as expected.
For data reporting differences between Opera Cloud and FLYR, see Data Differences Between Opera Cloud and FLYR Reporting.
1. Only Daily Rate Plans Are Supported for Price Updates
Description
For FLYR to push price updates to Opera Cloud successfully, the Base Rate Plan must be configured as a Daily Rate. Other rate types such as Standard or Advanced Daily Rate are not supported for price pushes.
If your Base Rate Plan is not a daily rate plan, price recommendations generated by FLYR will not be applied correctly in Opera.
Suggested Workaround
If your property uses a non-daily rate plan, create a daily rate plan and set up dependencies for your other rates accordingly. If you are unsure how to configure this, contact our support team and we can advise.
2. Overlapping Restrictions of Different Types
Description
Opera Cloud has a fundamental constraint in how it stores restrictions: for any given combination of rate plan + room type + stay date, only one restriction type can be active at a time.
Restriction types fall into three categories:
Arrival-based — Closed for Arrival (CTA), Minimum/Maximum Length of Stay on Arrival (ALOS)
Stay-based — Closed to Stay, Minimum/Maximum Stay Through
Departure-based — Closed for Departure, Minimum/Maximum Stay Departure
When FLYR sends two restrictions of the same type that overlap (e.g., a CTA and an ALOS2 on the same rate plan, room type, and date range), Opera handles this correctly and will hold only the currently active restriction of that type.
However, when FLYR sends two restrictions of different types that overlap on the same rate plan + room type + stay date, Opera can only hold one. This means that if the higher-priority restriction is later removed — for example, FLYR removes a tactical ALOS — Opera will not automatically reapply the other restriction that was effectively overwritten. It will simply be gone.
Example: A hotel sets a strategic Closed to Stay restriction at the rate plan level in FLYR. A tactical ALOS2 (arrival-based) restriction is then applied to the same date and rate plan. Because these are different restriction types, when FLYR later removes the ALOS2, the Closed to Stay does not reapply — it was already displaced. If the strategic restriction had instead been a CTA (also arrival-based), removing the ALOS2 would have correctly reinstated the CTA.
Suggested Workaround
To avoid this issue, follow these two principles:
1. Set strategic restrictions using the same type as FLYR's tactical restrictions. Your property's configuration determines which restriction type FLYR uses for tactical recommendations (e.g., arrival-based or stay-based). Strategic restrictions set manually in Opera should use that same type, so they coexist safely with any tactical restrictions FLYR applies.
2. Do not combine different restriction types that overlap in date and rate plan scope. Avoid a situation where, for example, a Closed to Stay is active at the rate plan level while FLYR is applying Arrival LOS restrictions on overlapping dates. If you notice a mismatch between restrictions in FLYR and Opera, contact our support team.
If you have any questions about how these behaviours may affect your setup, reach out to our support team. We're here to help.