Option field type vs. State Management

I do not like to use the Option field type for two reasons:

  • If you want to use, or replicate, the same field in others tables, you must remember where you have the same field because if you make a change you must replicate this change to all other tables.
  • If you add a new option, you must add it to the end to avoid that all your code point to a wrong option. To avoid it, you can do two things. The first is to save all your code in text format, add the option, load the text code, fix it and compile it. The second is to use numeric values instead the text options, like IF myTable.Status = 4 THEN instead of IF myTable.Status = myTable.Status::Sent THEN

The above mentioned has given me more than one headache in situations where I had the same field in multiple tables and I have had to add one or several options, because most likely all code compiles and does not give any error, but really is not correct.

State Management. The Basis

Due to this, I have been using a homemade functionality that I have called “State Control”. The “State Control” not only allows me to prevent against the annoying effects of add a new state to the flow control but it permits to the end user to change them (as long as it has not effect in the logic). Furthermore we can add a little of workflow behaviour, how we will see later.

The “State Control” prevents against the annoying effects of add a new state to the flow control

It is very simple. We start with two tables, one table to define the flow of state, and other for to control of the “current” state of something. Let us see it with an example.


We are going to use the fixed description (with the hope that it is not going to change) in the code, and we could use the free description to paint it on the page or factbox.


The state control table has relation of 1:1 with any other table of the system. The state control code can be the primary key of the related table. Although could also be a code auto-generated and linked with the table to control its states.


This is an example of how we can write code similar to the Option field type.

Later, if someone want to add some state to the flow it is such easy as add a register into State Flow table, like follow.


And, of course, your code has remained intact.
Now, you can add the code for the new state.


Furthermore, the same state flow can be reused as many times as you want.

State Management. Adding more functionality

To make the “State Control” more useful we are going to add some columns in the State Flow table.


First of all, we need add some code to the table we want to control the state.



And, optionally, we can move to backward and forward.



Even we can offer to user, across a standard dialog page, for he choose one.



And put it to the state appropriate.



We can also ask the “State Control” for the states we can move, using the “States Admitted”.


Also, we can have a Codeunit subscribed to State Control Management CU for to program the business logic needed.


In this example, something or someone wanted to change the state of a Ticket to Solved and a business rule has prevented it and send it to Cancelled state, because the customer had overdue balance.


Finally we need a Factbox to display information about the state of control. Something like this.


State Management. To finish

A lot of new things can be make over the “State Control” functionality. Here I put a few of them.

When a register of the State Control table has no changes for more than an established period of time, established in State Flow table, a background process can automatically change its state to another state like waiting state or something like that.

In the State Flow table we could add a check to indicate that someone (the owner, the customer, the manager, etc.) should be notified, and of course, point out where this person can be found.

By this way, when the State Control Management CU make a change of state, automatically will send a notification to whom corresponds or raise an event.

From the previous feature, or similar to the previous feature, we could force that a third people must approve a register of the State Control table for allow the change of the state.

Every time a register of the State Control changes, we could write in a State Control Log table and we could write down who and when the change of the state was realized.

From the State Control Log table we could determine how long a State Control has stayed in a determinate state, or who has less things in a determinate state, for example.

A panel that shows the percentage of completion with two lists, one that shows the stages completed and other that show stages pending.


NOTE: This is my first post written in English. I am apology for the mistakes.


2 respuestas a “Option field type vs. State Management

  1. I agree Option Lists are not the best solution but if you need a list and expect *some* growth, you can make provision by using extra commas to make space ready. I.e. If your option list is ” ,A,,,D” you have options A = 1, D = 4. B and C can be added later as options 2 and 3. The drop-down list in NAV will ignore the empty options.

    Le gusta a 1 persona

  2. That’s a good solution. I really liked it.

    Provably I would use the ELSE on the CASE pattern to get some kind of error if the value has not been controlled on development. That would ensure the code controls any new value a user could introduce on the possible values:

    ELSE StateControl.FIELDERROR(“State Flow Fixed Description”);

    Le gusta a 1 persona


Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s