you need to search the community to find the posts that can help you. All your questions were addressed probably several times already.
Now I just use TMF AI agent. It's much better than the forum's search engine.
from a documentation point of view, there is a lot to read in (too) many documents. GB922 Product and GB922 common have extensive chapter on policies and business rules (search for terms like *relationship", "policy", "rule" etc). IG1228 has a collection of use cases, some have example of product catalogue with business rules for broadband and mobile offers. but IG1228 has become difficult to read because it no longer show the use cases, you have to download them separately now. there are many more stuffs to read, but start with this. if you find my posts in the community I occasionally provide a comprehensive list of links on product domain.
If your rules a simple, the product catalogue has several ways to store at different levels (offer, spec, price) using the concept of "relationships". and the relationshipType indicate the purpose of the relationship (require, exclude, up-sell...).
if rules are complex, use the equivalent of TMF "Policy". They are plenty of vendors that have great solution for BRMS, solving engine, decision engine, Policy engine etc. but the policy should always be referenced (not stored) in the product catalogue (using policyRef).
Original Message:
Sent: Jun 18, 2025 09:50
From: Nabanit Kalita
Subject: Product Compatibility Rules
Hello Pierre G, Everyone
Following up on this old thread on the topic of how to handle Product Offer associations like pre-requisites, exclusions, cross sell etc in Product Catalog domain. Please do tell if there is a guidance from TMForum community on the same.
As we understand, such product offer associations/rules can be both enforcing ones (like pre-requisites, exclusions) and non-enforcing ones (like cross sell, suggestions) for run time consumers of this data. We do see these Product Data Model entities as falling under Product Catalog domain (and not experience entities like channel etc).
If we agree that these product offer associations/rules should be mastered by the Product Catalog, next point to figure out is the how part. Here we see multiple approaches possible:
- As association configuration on the Product Offer itself
- As separate data model entity (maybe something like an association matrix)
The benefit of the 2nd approach above is definitely around maintainability of the configured data (since it does not impact the base Product Offer configuration whenever such associations are to be established), however lifecycle management of such associations is to be looked into. The point related to maintainability comes up since usually such scenarios are very common for device and corresponding cross-sell/suggested accessories, and devices & accessories are high in quantity + Time to Market is always top priority for such scenarios.
Therefore, keeping the above in mind it will be really helpful to get collective view from the TMForum community on this topic.
Regards,
------------------------------
Nabanit Kalita
Telstra Corporation
Original Message:
Sent: Jun 27, 2019 16:22
From: SANTIAGO LORENTE JURADO
Subject: Product Compatibility Rules
@Paul Jordan I totally agree with you, except that we have the chance to review the current common policy model for all the use cases available at this time (vs a couple of them) to assure the model is robust enough to support current and futures needs.
Cheers.
------------------------------
SANTIAGO LORENTE
Pegasystems, Inc.
Original Message:
Sent: Jun 27, 2019 04:05
From: Paul Jordan
Subject: Product Compatibility Rules
Product Compatibility is not the only place where policy rules could be used; I have recently been thinking about the need to describe compatibility of hardware components and the need for policy rules to provide a limit or sanity check on the output of AI processes. It is good that the SID places policy in a ABE so that a common policy approach can be used for both Product and Resource problems. However the policy SID ABE has not been revised for some time and I question how widely it has been implemented.
It may be time to try using the common policy on two or more use cases, and either document how to use the policy structure or raise change requests on it.
------------------------------
Paul Jordan
BT Group plc
Original Message:
Sent: Jun 26, 2019 10:42
From: Jonathan Goldberg
Subject: Product Compatibility Rules
I don't think it would be appropriate for me to make any promises regarding timelines - I am an (active :)) member of the Open API team but I am not a leader. The API design work is done according to priorities set by the team leadership and availability of the team members (from CSPs and vendors).
I refer you to the chief Open API architect @Pierre Gauthier who might be able to give his ideas of the vision in this area.
Hope it helps.
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Original Message:
Sent: Jun 26, 2019 09:05
From: santiago lorente
Subject: Product Compatibility Rules
Thanks Jonathan
it will be nice if you can post here a link to the roadmap for adopting these capabilities in a timeline.
Cheers.
------------------------------
santiago lorente
Pegasystems, Inc.
Original Message:
Sent: Jun 26, 2019 01:53
From: Jonathan Goldberg
Subject: Product Compatibility Rules
We are aware of the SID Policy model, which follows the ECA paradigm (Event, Condition, Action), and we have also seen alternative models.
A concrete proposal for how the Policy model should appear in the Open API will depend on a more detailed analysis of use cases and flows, that is part of the API design process.
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Original Message:
Sent: Jun 20, 2019 11:50
From: santiago lorente
Subject: Product Compatibility Rules
Hi Jonathan Goldberg,
It is good what you said in your previous post "The Open API team believe that rules should be handled as an external set of entities called Policy. We have the intention to introduce a Policy API to deal with management and execution of Policy rules (based on the SID Policy ABE model)".
However, it could be some incongruencies the team should look around in SID. For example, if you look into the "GB922_Product_R18.5.1" document, there is a whole section that talk about Policies rules and how this is applied to calculate the prices of a whole Product Offering Price Rule: "The price of a ProductOffering is governed by a PolicySet. The PolicySet may be a single PolicyRule or a PolicyGroup which ties together a number of PolicyRules. The use of both single rules and grouped rules will be explained via examples."
Having a first OPEN API docs like the one you mention is good, (API, TMF 679,) however without a proper support inside the information model (SID) it is partial solution.
Cheers.
------------------------------
santiago lorente
Pegasystems, Inc.
Original Message:
Sent: Jun 19, 2019 03:55
From: Jonathan Goldberg
Subject: Product Compatibility Rules
Hi
Thanks for these posts raising the need to deal with rules in catalogs.
The Open API team believe that rules should be handled as an external set of entities called Policy. We have the intention to introduce a Policy API to deal with management and execution of Policy rules (based on the SID Policy ABE model). Clients of Policy, such as Product Catalog management, would include references to Policy as part of their model. And as you correctly point out, these policies would be executed in runtime - for instance product catalog policies would be executed as part of the sales and order capture process.
The specific use case for product offering qualification is covered by an existing API, TMF 679, I advise you to examine that API to see if it meets your needs (the API table is available at https://projects.tmforum.org/wiki/display/API/Open+API+Table).
Since we do not yet have a concrete plan for this enhancement, we advise you to make an extension in your specific implementation of the catalog API.
Hope it helps
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Original Message:
Sent: Jun 14, 2019 00:36
From: Ashish Doodhwala
Subject: Product Compatibility Rules
Let me share my thought,
Rules applied on catalog enities are primarily to used for run time activities e.g. browsing the catalog.
Rules can used to cater various business scenarios , some of them are listed below
1) To make PO available based on customer type, market segment , geography etc
2) use cases , where product Offerings (product) have dependency (affinity or inaffinity relations) . e.g. International roaming pack only available with base plan , purchase of offer only allowed if similar offer is expired etc. The scenarios , for me will make use of compatibility rules.
Rules extend the dyamic nature of catalog and to make it more flexible for operational use.
For the reasons, my first inclination to attach rules at PO level.
------------------------------
Ashish Doodhwala
Ericsson Inc.
Original Message:
Sent: Jun 13, 2019 10:56
From: Al Bastien
Subject: Product Compatibility Rules
I second this question. We have been implementing the rules to execute from Product Order when a product is added, but I am not sure this is the intended way. We do have product incompatibilities being returned from Product Catalog. I am not sure the exact details. But these and other rules are also executed during product order patch calls.
------------------------------
Al Bastien
IBM Corporation
Original Message:
Sent: Jun 06, 2019 05:19
From: Edwell Dombodzvuku
Subject: Product Compatibility Rules
Hi,
This is my first involvement with the Product Catalog API, and we've made a fair stab at modelling significant portions of our ProductSpecification and ProductOffering resources and mapping from our legacy catalog.
I would like to know how product compatibility rules are supposed to be modelled into the Product Catalog API, should they be modelled into the ProductOffering specification or should they be modelled into another Entity? How do other operators achieve this for purposes of supporting catalog exchange or Configure-Price-Quote (CPQ) capabilities?
Regards,
Edwell
------------------------------
Edwell Dombodzvuku
Aesopia
------------------------------