Workflow & mandatory fields

new concept warning!

This is the first time I blog about “forms & data”, one of my areas of interest, deep knowledge and also – income. What surprises me is that there are several concepts either missing or used but never described in literature. What’s dumb about that is that when you talk to customers, you are always talking about new concepts that need to be described anew – sometimes repeatedly. So here goes …

When data has to be entered into an input mask (which is about the same as filling in a form), for years now we have known mandatory fields, i.e. mask fields that need to be non-empty when the mask is “stored” somehow. Almost all DB-based systems have that. From the DB’s point of view, all the DB really needs to store a record (which is roughly the contents of a mask) is one key field, whereas for each other data field it is up to the SW designer, whether the field is marked as “absolutely necessary” or – not. Now this has been great for the last 20 odd years, but the moment a set of data is being filled in more than one session by more than one person, one person’s disabled field may be the other one’s mandatory field; so let us put a little system behind that which might well be called

the life-cycle of  a DB field

a field on a data entry mask can have the following states, depending on the user who is looking at the mask:

– visible, empty and disabled

– enabled and optional

– mandatory

– enabled for change

– visible and disabled

a workflow system will support this and it becomes obvious that there is nothing such as a “mandatory field” in a DB record. It’s dynamic! It’s one order higher in complexity than 20 years ago. Clicking a checkbox at DB design time is not enough. Some scripting may be required.