@Ajay Saini
The reason I don't want to keep it in the experience layer is that, in my opinion it is not good practice to place business logic there.
I wrote the same thing. Business logic should reside in backend, presentation logic should reside in frontend
Should we drive it via POQ now?
There is a few options but I'll share two.
1. Use a Product configuration service (TMF760)
Since Basic, Standard , Premium are product offers bundled in a broadband plan. I assume end users will interact with the equivalent of a Product Configurator that will present the OTT options for their current broadband plan.
TMF760 can compute a productConfiguration for your Broadband Plan which contains both the OTT play customer bought previously (active in inventory) and available OTT play offers. the OTT Play that are not selectable because they are downgrade, have this attribute:
"isSelectable": true/false,
the upgrade or downgrade rule is stored in the product catalogue and exposed by its API, for instance TMF620 via productRelationships.
2 Product Eligibility Service (TMF 679)
Ask, "From OTT Play Basic, what can I upgrade to?"
POST /queryProductOfferingQualification
{
"searchCriteria": {
"product": { "id": "1234" }, // current active OTT Play Basic
"action": "upgrade" // Optional *
}
(this request is simplified)
Comments:
- "
action" is not native to TMF679; we borrowed it from TMF 760 because a bare product‑ID does not convey customer intent. It's very useful.
- When the rule depends on the parent broadband plan, include that plan in
qualificationItemRelationship to give the rule engine full context.
and the response would look like (again very simplified)
200 OK
{
"id": "QPOQ‑9001",
"href": ".../queryProductOfferingQualification/QPOQ‑9001",
"qualifiedProductOfferingItem": [
{
"productOffering": {
"id": "1235",
"name": "OTT Play Standard"
},
"qualificationResult": "qualified"
},
{
"productOffering": {
"id": "1236",
"name": "OTT Play Premium"
},
"qualificationResult": "qualified"
}
],
"effectiveQualificationDate": "2025‑07‑18T12:43:07Z"
}
BTW, Product Configuration service can also call TMF679 to get that list of eligible upgrades and then set "isSelectable": true or false for each bundled OTT offers.
I would have preferred a response that also includes unqualified items with ineligibility reason, (like we have with queryProductOfferingQualification). This would allow me a better personalised UX for the customer.
------------------------------
Kind regards,
Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS
------------------------------
Original Message:
Sent: Jul 18, 2025 00:06
From: Ajay Saini
Subject: Clarification on Display Logic for Upgrade-Only Digital Services During Plan Changes
Thanks @Matthieu Hattab for the detailed information.
I would like to add that this business rule is not tied to a specific sales channel. The reason I don't want to keep it in the experience layer is that, in my opinion it is not good practice to place business logic there.
Should we drive it via POQ now? Any thoughts?
Thank you
------------------------------
Ajay
Original Message:
Sent: Jul 17, 2025 10:24
From: Matthieu Hattab
Subject: Clarification on Display Logic for Upgrade-Only Digital Services During Plan Changes
Hello,
You could use POQ, I actually did that in the past by creating an eligibility rule to control what a user can purchase based on the sales channel. Ineligibilityreason would say "not available in this channel". Then FrontEnd could filter out downgrades offers that are not "eligible"
However, I wouldn't recommend that approach today.
This is a good opportunity to clarify the distinction between business logic and presentation logic.
In your case, the logic is contextual and driven by the user interface and user intent. You're not forbidding a downgrade; you're simply choosing not to display the option in a specific context, namely, the self-service telco app channel.
This aligns with the ODA principle of separating Core Commerce Management from Engagement Management.
Recommendation
Use your experience/data orchestration layer or whichever middleware/BFF sits between your frontend and backend, to adapt content and logic based on frontend context and user intent. That's its core responsibility.
Other Options
EPC/PCM or PIM/PXM
If you prefer to manage this in the backend, you could use TM Forum's TMF620 API. It allows you to define productRelationship, listing upgrade/downgrade options.
However, TMF620 won't tell you whether a downgrade is not allowed in a particular channel like your self-service app. You'd need to create a dedicated product catalogue for that channel and exclude downgrade paths; making your catalogue opinionated, which has drawbacks.
TMF620 offers another approach
The allowedAction element can reference a specific channel (based on TMF examples in IG1228 and TMF760).
This means you can define whether a customer is allowed to downgrade, upgrade, terminate, move, etc., depending on the channel context.
Other less ideal options (e.g., CMS) exist, but are best avoided.
------------------------------
Kind regards,
Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS
Original Message:
Sent: Jul 16, 2025 06:15
From: Ajay Saini
Subject: Clarification on Display Logic for Upgrade-Only Digital Services During Plan Changes
We are offering digital services bundled with our telco broadband products-such as OTT Play, etc. For example, a customer may receive a OTT Play Basic subscription included with a broadband plan.
As part of this offering, we have a requirement to restrict the display of downgraded digital service options (e.g., OTT Play plans) during the change plan workflow of OTT Play from telco app. Specifically, non-telco digital products (like OTT Play) that fall below a designated baseline (e.g., the product included in the original broadband bundle) should not be shown to the customer. This ensures that:
Customers cannot downgrade their digital service (e.g., OTT Play) below the "X" baseline level included in the bundle.
Only upgrade paths are allowed-e.g., from Basic → Standard → Premium.
If a customer currently has OTT Play Standard, the system should not allow OTT Play Basic to display it as an option.
We maintain a digital services product catalog and currently use the Product Order Qualification (POQ) API for validating product eligibility during ordering flows.
Question:
To enforce this upgrade-only logic for digital services, particularly for controlling visible plan options during the change workflow, can we leverage the POQ API as per TM Forum standards? Or would other TM Forum APIs be more appropriate for implementing this logic?
Thank you.
------------------------------
Ajay
------------------------------