Skip to main content

myEvolv Tips: Custom Sort on User-Defined Fields

It is possible to display your user-defined picklist options in a custom order in myEvolv. This comes in handy when you are using a user-defined table for things like scales where the description would not naturally be in alphabetical order.

This recently came up for a form I was working on where the user needed to determine if a score on a test was

  • None
  • Low
  • Moderate/Low
  • Moderate
  • Moderate/High
  • High
  • Very High

When I created the User-Defined Table, the picklist displayed the options in alphabetical order, which is not an intuitive order for the user to see this kind of list displayed.

How can I get the picklist to display in the logical order? The answer lies in the user-defined table setup. In the table definition section, there is a field called “Order Expression”. It will take any SQL code that would follow ORDER BY in an order by clause.

The default value is description which means it will sort the description column in ascending order.

You could change the value to description desc to change the order to reverse-alphabetical.

You can also change which column the sort is applied to. With user-defined fields that means you can use the Shortcut Code, Standard Code or Generic Code columns. The trick is that you have to know the actual column name in the table. Here they are:

Shortcut Code = sc_code
Standard Code = std_code
Generic Code = gen_code

Keep in mind that the shortcut code is usually also displayed in the picklist and/or used on the form as a way of typing in the selection so you may or may not want to use that column as your sort column.

In my case, I went with using the Standard Code column. I simply put a number for each row in the order I wanted them to display and changed the Order Expression to std_code.

Setup like this, my picklist is now sorted in a logical fashion:

myEvolv Tips: Reusable User-Defined Picklist Fields

When you are building forms and have to create new database fields, best practice is to give the columns generic names so that you can use them again on other forms in the same form family. For example, if you need to link a tenth diagnosis (yes, the event_log has 9 diagnosis columns!) on a People Activities form, you should name it something like udf_diagnosis10_id rather than for the specific form like udf_extradiagnosisforclinicprogressnote. This will allow you to keep your database neat and help prevent running out of columns in your _x tables.

You may have run into a situation where you setup a user defined foreign key field on one form and had it working beautifully. However, when you went and tried to re-use it on a second form, you found that you could not select any look-up tables to use with it. What happened there?

You missed a crucial step in creating a user-defined database field. Here’s how to avoid making that same mistake going forward.

When you got to create a user defined foreign key field, use the [Data] Foreign Key Column attribute. Like the column name and data type, this attribute is only available when you first create the new column. If you forget this step, you cannot go back, and it is the reason that you cannot link a look-up table on subsequent uses of this column on other forms.

What to choose?

This depends on what picklist(s) you want to use with this column.

For example, if we go with the initial scenario, the picklist I want to use will consist of diagnoses so the foreign key column I want to select is diagnosis_id. This will allow me to reuse the column on additional forms as long as I use a picklist that is diagnosis-based.

User defined fields are commonly paired with a user defined look-up table. In order to re-use these, you should select the user_defined_lut_id foreign key column. Since all of your user defined look up tables use the user_defined_lut table, they all use the same column as their primary key.

If you need help figuring out which column to select, first select the look-up table you intend to use. In the picklist for look up tables, there is a column called “Table From”. Many of these will be views, but you should be able to figure out what the underlying table is in most cases. In our example, I want to use a look-up table from the diagnoses_view and so I know that the diagnosis table and therefore the diagnosis_id column is what I should select.

We are using cookies on our website

Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.