Conditional Feeders in TM1 – Explained with Examples

Feeders are used in TM1 to “turn on” rule calculated cells. With them TM1 is blindingly fast as only required intersections are calculated. Conditional feeders can be used to minimize the rule save time and storage impact of rule feeders. The typical situation occurs when rule values are calculated by multiplying factors, any of which may be zero. This means that the value should be fed only when all the factors are non-zero.


Given a cube ‘SalesCube’ with dimensions:

  • Salesperson,
  • Product,
  • Month,
  • Measures (‘Sales’ and ‘Commissions’)

If you calculate Commissions based on Sales using a commission rate as follows:

['Commissions'] = N:['Sales'] * db('CommissionRates', !product, !month);

Commissions should be fed from Sales, but only if the commission rate for the product in the month where the sale occurs is non-zero.

This can be accomplished by a feeder of the form:

['Sales'] => db( cubename, !salesperson, !product, !month, 'Commissions');

Here, cubename needs to be a conditional expression that results in a blank if the corresponding commission rate is zero. Since a blank cube name cause the feeder to be ignored, the required effect is produced.

Conditional Expression

The complete conditional feeder would then read:

['Sales'] => db( if( db('CommissionRates', !product, !month ) = 0, ' ', 'SalesCube'), !salesperson, !product, !month, 'Commissions');

NOTE: The above example assumes that commission rates do not change. If a commission rate were to change from zero to a non-zero value, the required feeder would not re-fire. Please see below for discussion around how to manage this.

Workaround 1

To remedy this problem with conditional feeders in the CommissionRates cube, write a feeder as follows:

[] =>db(


        'All Salespersons',




This result is less than ideal This is because we cannot write a conditional expression based on the sales to feed only those salespersons that have non-zero sales. Therefore all salespersons must be fed, which results in overfeeding.

Workaround 2

A different way of ensuring conditional feeders are performed is to re-process the feeders from SalesCube whenever CommissionRates is changed. This can be done by either:

  • Re-compiling the rules for SalesCube
  • Executing CubeProcessFeeders(‘SalesCube’) from TurboIntegrator.

Note that re-starting the server will also ensure all feeders in all cubes are re-processed. This is normally not recommended because, depending on how many cubes need to be fed, it may take an unnecessarily long time.

Two-Way Conditional Feeders

If commission rates are variable by salesperson (the CommissionRates cube had the same dimensions as SalesCube), you can write two-way conditional feeders as follows:

In the SalesCube cube:

['Sales'] => db( 

if( db('CommissionRates', !salesperson, !product, !month ) = 0, ' ', 'SalesCube'), 

!salesperson, !product, !month, ‘Commissions’);

In the CommissionRates cube we create a conditional feeder as follows:

[] => db( 

if( db('SalesCube', !salesperson, !product, !month, 'Sales') = 0, ' ', 'SalesCube'), 

!salesperson, !product, !month, 'Commissions');

Reevaluating Conditional Feeders

In some instances when conditional feeders are used in rules, a change in the condition value does not trigger the feeder. For example, suppose your rule has the following feeder structure:

  • Cell A feeds cell B.
  • Cell B feeds cell C when condition D is true (this is the conditional feeder).

Assuming condition D is false, a change in the value of cell A triggers feeding of cell B, but the feeding of cell B does not trigger the feeding of cell C. This is because at this point, condition D is false, and cell C is fed only when the condition is true.

Now, if condition D subsequently becomes true but the value of cell A does not again change, cell C remains unfed. This can lead to inconsistencies in data

If you add the line ReevaluateConditionalFeeders=T to the Tm1s.cfg for your server, any changes to cell values referenced by conditional feeders will force the feeder to be re-evaluated. If ReevaluateConditionalFeeders is not enabled in the Tm1s.cfg file, feeders from numeric cells are executed only when the cell changes from being zero to having a nonzero value.

In the above example, any change to a cell value that causes condition D to become true would force a re-evaluation of the conditional feeder, resulting in cell B feeding cell C.

ReevaluateConditionalFeeders is an optional parameter that must be explicitly added to Tm1s.cfg.

Other changes to the cube, such as changes to attributes, do not force the feeder to be re-evaluated. Only cell value changes trigger the re-evaluation.

You might also like