Understood…. Not required though, your choice.
I'm just now trying to grok the whole thing. I see what you mean by not wanting to record that as an event. Looking at it now, I tend to agree, I wouldn't either. on a fairly simple system.
But let me relay a problem I've encountered recently in a different workflow I work with. Notes is really good at recording the current state of things, but when it comes to triggering things based on the transition of state it can get really hairy. Suppose I had a workflow that had the stages, "initial" ,"in production", "delivered", and over time, the "cancelled" stage for a contract tracking system… Works great as long as it is self contained. But when you have to interface it with another Oracle backend system that is trying to record every little state change. Transitions like "when did this thing change from "delivered" to "cancelled", and when did it get uncancelled and sent back to production or sales? Its tough if you don't have codes for everything. If you have to rely on a set of constant includes etc., its almost like hard coding, particularly when you have to check against them, and for multi-language support, its best to use codes rather than text. Probably the better thing to do would be to configure each and every choice as you did with the user choices, even the system ones, like that one, and then give each choice an attribute of "recordable" or some such. That way, its up to the routine that records history to figure out from the configuration if it should record it or not.
Just my 2 cents.
-Bill Wheaton
Lotus 911