The default process models internally enable/disable the PostResultListEntry callbacks in ways that aren't intuitive to users seeking to quickly edit a callback to customize/override behavior.
It would be nice to see that instead of simply turning off the callback (leaving users to wonder why their override doesn't work like all the others, except if they read the help/ or think to turn on 'on the fly reporting') as part of the process model based on the options....
(1) leave the callbacks on and move the 'on the fly' logic into an IF defined section within the sequence
(2) make a second PostResultListEntrys style callback that's explicitly for 'on the fly' that is in addition to other PostResultListEntry behaviors that a user may want to enable/add.
I've had several customers now who have designed custom event loggers / reports around the ProcessModelPostStep callback (with some rather convoluted logic where they dig for results) simply due to the fact that they couldn't understand why their PostResultListEntry callbacks didn't work.... or that they didn't feel comfortable editing the process model in order to remove the logic that force the callback to be disabled when not 'on the fly' and also keep the 'on the fly' reporting unharmed if they want it later.
Cheers,
Elaine R.
Cheers,
Elaine R.
www.bloomy.com
