Open APIs

Hi there,

We have an DTH box with a Music App. If a customer already has an active broadband or postpaid connection, we want to offer them the option to subscribe to Music App with "Add to Bill" with Broadband or postpaid.

Eligibility condition is purely based on the customer having an active broadband or postpaid service in our systems - it's not a catalog-level product qualification.

As per TM Forum Open API and functional architecture, which system should own and implement this eligibility check?

I would like to know the recommended best practice so that we keep business rules and these types of eligibility checks in the right place, aligned to TMF principles.

Thanks

------------------------------
Ajay
------------------------------

Hi,

I would suggest to take a look at the TMF679 Product Offering Qualification Management API.

Regards,

------------------------------
Yigit Kilic
Solution Architect
Telenor Sverige
------------------------------

Hi,

your description suggests it's a commercial qualification.

tmforum would recommend:

• The ODA component is TMFC027 
• the API is TMF679

you can find examples and guidance in

• the API guide and in the API YAML file
• the ODA specification document
• Document IG1228 to see some end-to-end use cases involving TMF679 and TMFC027

All document are downloadable from TMF main website (use the search box)

• there is ten, maybe hundreds, of discussions in the tmforum Community (this is where you are now)

------------------------------
Kind regards,

Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS
------------------------------

@Matthieu Hattab @Yigit Kilic TMF679 uses product offering id and on that it gives whether customer is eligible to buy this product offering or not. My usecase is not on particular product offering, my check purely based on the customer having an active broadband or postpaid service then provide add to bill on channel layer for music app.

Should this type of eligibility to be done via 679? If yes how I can structure the request of tmf 679 API

 

------------------------------
Ajay
------------------------------

Original Message:
Sent: Aug 13, 2025 08:05
From: Matthieu Hattab
Subject: Which TMF-compliant system should handle eligibility check for "Add to Bill" based on existing services?

Hi,

your description suggests it's a commercial qualification.

tmforum would recommend:

• The ODA component is TMFC027 
• the API is TMF679

you can find examples and guidance in

• the API guide and in the API YAML file
• the ODA specification document
• Document IG1228 to see some end-to-end use cases involving TMF679 and TMFC027

All document are downloadable from TMF main website (use the search box)

• there is ten, maybe hundreds, of discussions in the tmforum Community (this is where you are now)

------------------------------
Kind regards,

Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS
------------------------------

Original Message:
Sent: 8/20/2025 9:11:00 AM
From: Ajay Saini
Subject: RE: Which TMF-compliant system should handle eligibility check for "Add to Bill" based on existing services?

@Matthieu Hattab @Yigit Kilic TMF679 uses product offering id and on that it gives whether customer is eligible to buy this product offering or not. My usecase is not on particular product offering, my check purely based on the customer having an active broadband or postpaid service then provide add to bill on channel layer for music app.

Should this type of eligibility to be done via 679? If yes how I can structure the request of tmf 679 API

 

------------------------------
Ajay
------------------------------

Hi,

The right way to do this is through Product catalog. There are advantages if that pattern is followed. Even if it is not billable and not provision-able on your network nodes, it still makes sense to model it as a product and have the eligibility rule against broadband service = active in the PI instance.  

As Matthieu suggested, TMFC 027 is the right component (The product Configurator component). But for this the product must be modelled in TMFC001 and the instantiation should be available in TMFC005. 

Deviations from this pattern will lead to problems later on.

Regards,

Jag

------------------------------
Sri-Jagadish (Jag) Baddukonda
ServiceNow, Inc.
------------------------------

@Jag Baddukonda,

Do you have recommendation on how you model this in 620?

productOfferingRelationship is pairwise. If you add two requires relationships (A→B, A→C), most engines will read that as AND, not OR.

TMF has added PolicyRef to externalise complex rules outside TMF catalogue (but still have a reference in the catalogue)

There are solutions if you want to be very creative:

• the require rule is done between (PS requiring a PS bundle)
• bundle broadband and postpaid in a helper product with a bundleGroup, and build the require rule between Music and the helper product.

Those are quite exotic solutions and it won't be plain sailing

------------------------------
Kind regards,

Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS
------------------------------

Original Message:
Sent: Aug 14, 2025 08:07
From: Sri-Jagadish (Jag) Baddukonda
Subject: Which TMF-compliant system should handle eligibility check for "Add to Bill" based on existing services?

Hi,

The right way to do this is through Product catalog. There are advantages if that pattern is followed. Even if it is not billable and not provision-able on your network nodes, it still makes sense to model it as a product and have the eligibility rule against broadband service = active in the PI instance.  

As Matthieu suggested, TMFC 027 is the right component (The product Configurator component). But for this the product must be modelled in TMFC001 and the instantiation should be available in TMFC005. 

Deviations from this pattern will lead to problems later on.

Regards,

Jag

------------------------------
Sri-Jagadish (Jag) Baddukonda
ServiceNow, Inc.
------------------------------

Maybe one way is to define a bundledProductOffering (Broadband + MusicApp) where the in the bundle the broadband offer+PS is mandatory (min=1, max=1) but Music App is optional (min=0, max=1)

So adding the musicApp later(e.g. day2 order) is adding a related product to the bundledProduct in the product inventory.

Postpaid connection(Guess this is like a mobile voice line?) I suppose then is another bundleProductOffering again bundling the same MusicApp (productOffer+PS)

So then the rule is kept on TMF620.

------------------------------
Yigit Kilic
Solution Architect
Telenor Sverige
------------------------------

Original Message:
Sent: Aug 14, 2025 09:18
From: Matthieu Hattab
Subject: Which TMF-compliant system should handle eligibility check for "Add to Bill" based on existing services?

@Jag Baddukonda,

Do you have recommendation on how you model this in 620?

productOfferingRelationship is pairwise. If you add two requires relationships (A→B, A→C), most engines will read that as AND, not OR.

TMF has added PolicyRef to externalise complex rules outside TMF catalogue (but still have a reference in the catalogue)

There are solutions if you want to be very creative:

• the require rule is done between (PS requiring a PS bundle)
• bundle broadband and postpaid in a helper product with a bundleGroup, and build the require rule between Music and the helper product.

Those are quite exotic solutions and it won't be plain sailing

------------------------------
Kind regards,

Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS
------------------------------


Original Message:
Sent: Aug 14, 2025 08:07
From: Sri-Jagadish (Jag) Baddukonda
Subject: Which TMF-compliant system should handle eligibility check for "Add to Bill" based on existing services?

Hi,

The right way to do this is through Product catalog. There are advantages if that pattern is followed. Even if it is not billable and not provision-able on your network nodes, it still makes sense to model it as a product and have the eligibility rule against broadband service = active in the PI instance.  

As Matthieu suggested, TMFC 027 is the right component (The product Configurator component). But for this the product must be modelled in TMFC001 and the instantiation should be available in TMFC005. 

Deviations from this pattern will lead to problems later on.

Regards,

Jag

------------------------------
Sri-Jagadish (Jag) Baddukonda
ServiceNow, Inc.

Hi Matthieu,
I agree on the creative modelling pattern you proposed. We need to discuss the usage of Policy Ref in Sales Catalog bundling to enforce some of the rules. 

@Jonathan Goldberg

@David Milham

But in reality (this needs to be confirmed by Ajay Saini), do they have two bundles, one wth Broadband and one with Mobile pack and make the Music App optional in both the separate bundles or is there one bundle where either Broadband OR Mobile (or maybe AND) are selected. If it is OR, then one of them becomes mandatory. 

And the music App is optional.

I am assuming it is 2 bundles into which the Music App as an optional item is added. 

------------------------------
Sri-Jagadish (Jag) Baddukonda
ServiceNow, Inc.
------------------------------

Original Message:
Sent: Aug 14, 2025 09:18
From: Matthieu Hattab
Subject: Which TMF-compliant system should handle eligibility check for "Add to Bill" based on existing services?

@Jag Baddukonda,

Do you have recommendation on how you model this in 620?

productOfferingRelationship is pairwise. If you add two requires relationships (A→B, A→C), most engines will read that as AND, not OR.

TMF has added PolicyRef to externalise complex rules outside TMF catalogue (but still have a reference in the catalogue)

There are solutions if you want to be very creative:

• the require rule is done between (PS requiring a PS bundle)
• bundle broadband and postpaid in a helper product with a bundleGroup, and build the require rule between Music and the helper product.

Those are quite exotic solutions and it won't be plain sailing

------------------------------
Kind regards,

Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS
------------------------------


Original Message:
Sent: Aug 14, 2025 08:07
From: Sri-Jagadish (Jag) Baddukonda
Subject: Which TMF-compliant system should handle eligibility check for "Add to Bill" based on existing services?

Hi,

The right way to do this is through Product catalog. There are advantages if that pattern is followed. Even if it is not billable and not provision-able on your network nodes, it still makes sense to model it as a product and have the eligibility rule against broadband service = active in the PI instance.  

As Matthieu suggested, TMFC 027 is the right component (The product Configurator component). But for this the product must be modelled in TMFC001 and the instantiation should be available in TMFC005. 

Deviations from this pattern will lead to problems later on.

Regards,

Jag

------------------------------
Sri-Jagadish (Jag) Baddukonda
ServiceNow, Inc.

Hi Ajay, great question. I faced a similar challenge while working on an "Add to Bill" use case during a Salesforce + external system integration.

Based on TMF Open API and functional architecture, the eligibility check should ideally sit within the Customer Management / Subscriber Management domain, not directly in the Catalog. Since your condition is service-level (active broadband/postpaid) rather than product-offer qualification, the Customer/Service Management system is best placed to validate eligibility.

The Catalog can still drive what's possible to sell, but the Customer/Service domain ensures the check is performed against live customer subscriptions, keeping business rules consistent with TMF principles.

------------------------------
Maxwell Lord
TO BE VERIFIED
------------------------------