Do you have a situation where updating one place in CPQ should trigger all Configured Product using this information to be re-configured just to find that CPQ isn’t reacting?
Tacton CPQ have a function for informing a user that a configuration needs to be updated due to changes in data used from within CPQ.
But that doesn’t work if you are uploading a tcx file.
If you have been challenged by this, then here’s a way to use trampolines and life cycles to get around.
This article is a deep dive and requires that you have been working in the Tacton CPQ Administration environment.
Let’s say you have you have some parameters under for instance the customer (Account) that you are using every time you configure a product as input to in your model. What happens when you update these information? Well nothing, as there are no direct link between customer and a configured product. The link is by standard established via:
But what happens if you change anything under Account?
Nothing under any existing Configured Products. The changed value is not discovered under an existing product. Only if the user opens an existing configuration are the new value read and used. So how to make the user aware that they are using updated information in their Configured Product?
We need to trigger all related Configured Products that an change have happened in an object from where it uses information.
Trampolines needs a user to be able to run, that means we need to find a way to get the user that changed the information under Account to run the code either manually or by using a life cycle transition.
You need to work with the following to trigger this:
- Use life cycles in both objects (Account and Configured Product in this case) to start/force a trigger and to update each related Configured Product.
- Write a trampoline code that touches all related Configured Products.
- Create attributes to control life cycle pre-conditions and tell the user that they need to re-configure.
We want all Configured Products related to an Account to be touched (saved) for enabling us to inform an end user that re-configuration is needed depending on the state of existing Configured Products.
We will block updating of Account attributes in certain stages (like draft/approved) for us to control when to activate the trampoline code.
Our trampoline code are using the standard functions below to loop through all Configured Products listed to an Account
findAll(connection c, string resource, list attributes, object conditions)and then transition them to our new create life transition to re-save the existing Configured Products.
transition(connection c, string resource, string id, string transition, string comment)That’s it, or that explain in general how it can be used. The actual setup depends on your workflow and needs.