Conditional Value Lists Pt 1 - What Are They & How to Build Them
September 13, 2010 By Daniel
Conditional Value lists may be the most asked about piece of functionality on the FileMaker Cafe. To try and provide a thorough and easy to follow explanation of what they are and how they work, I decided to write an article on the subject and build a small example file to help illustrate the technique.
What is a conditional value list?
A conditional value list is any value list whose contents can dynamically change. The most common method to change a value lists values is to change the contents of another field. In this case, the values that are displayed in the value list are dependent upon the value in the field. Indeed, the terms conditional and dependent can be interchangeable.
Why are they used?
Conditional value lists are a great way to narrow down the size of large value lists by breaking them down into smaller manageable lists. They also help when you need to select values for 2 or more fields. The easiest way to show this is to jump straight in with a straightforward example.
Sport Equipment Example
I have a database that is used for recording a large variety of sporting equipment. I have a sport table that contains the following fields:
• Sport Category
• Sport Name
• Sport Equipment

Each item of equipment can be categorised into a specific sport, and that sport falls into a specific sporting category. Examples of sporting categories might be Ball sports, stick sports, contact sports. A sport name might be Hockey, and for that sport the equipment could be a stick, a puck, a net, or gloves.
Lets imagine now, that the database also acts as a way to hire out sporting equipment. When a piece of equipment is hired out to someone, a record is created in the database, and that item of equipment is captured on the record.
One field, one value list?
The piece of sporting equipment could be recorded into a single field. One of the problems with this is if there are many thousand items of sporting equipment, the value list is very large and may be tedious to select the item.
Consider also, that many sports contain the same type of item. for example Netball, Basketball, and Ice Hockey all have nets, so if you chose "net" as the item of equipment, how would you know what type of net it is ?
Three fields, three value lists
A more clear solution is to define the item of equipment as a category, name, and the item itself - basically use the fields already in the sport equipment table.

The first step is to select a category - there are far fewer sporting categories than there are items of equipment, so selecting a category should be very easy.

With a category chosen, the next step is to choose a sport. There is no value in showing EVERY sport, instead, what you would expect to see is just the sports that are of the category you have chosen. Again this will keep the list of sports much smaller and more manageable.

Lastly, to select an item of equipment, you would expect to only see items of equipment that belong to the sport you have chosen, which itself belongs to the category you have chosen.

Constructing the Value Lists
The category value list is easy. It's just a straight up value list of all sport categories from the table. The "All Values" option is used in the value list.
The sport Name value list is the first of the "conditional" lists. Conditional value lists are built using the "Include only related values starting from" option in the value list setup. Because of this, conditional value lists also require you to create a relationship for the purpose.


In the image above, I have created a relationship between my main table (which contains the fields I am entering values into), and the Sport Equipment table. The condition on the relationship is Sport Category = Sport Category. This means the relationship is setup to only find sport Equipment whose category is the same as the category I have chosen. That is the condition. By building a value list based on this relationship - the value list will also only show sport names which belong to the category I have chosen. Note that relationships & value lists are basically the same thing - the value list is showing records through the relationship you define.

Here, you can see the value list built that is based on the relationship created above. The field the value list is displaying is Sport Name through the relationship. The most important part of the setup is the "Include only related values starting from" option - in this case it is set to "Home" which is the table occurrence on the left hand / source side of the relationship.
The end result is a list of sport names for the chosen category.
Taking this principle to the next step, the Sport Equipment field can have a value list built which shows just equipment for the chosen category AND name. In this case, the condition is that my chosen sport category AND name, matches all Sport equipment records with the same category and equipment.

Here is the relationship created for the second value list construction. The two conditions are specified.
The value list is built in the exact same way as the one for Sport Names, however this time the new relationship is chosen, and sport equipment will be the field in the value list.

(the results of all 3 value lists are shown in the earlier pictures).
Final Thoughts…
That's it, it's just that simple. Conditional value lists are built using relationships. the condition part refers to the fact that the values are dependent upon a value you choose in another field - that field is then used in the relationship to narrow down the records through the relationship - and thus the records in the value list.
Example File
Please find attached an example file. This file was used for all the screenshots in this article, and is fully commented to help you fully understand what is going on in the file.
Comments
Jon
03 April, 2011
Want to say thanks for your blog, it's been a breath of fresh air as I try to learn some more complicated things for my database. I do have a quick question though.
Can conditional lists be used with calculations as well? Let me explain.
Currently I am working on a database for managing bands and shows that they play. At the end of the night there are many factors that determine how much money the band gets paid. First of all there is a guarantee amount, say $500. Often times the band will get a percentage of the door funds. Venues will say, in additional to your guarantee, you will receive 20% of the door funds.
Other times the venue will say you get your guarantee or 80% of the door, whichever is more.
I want a conditional value that is allows me to choose where the door funds are in addition or in replacement to the guarantee. This selection will dictate in my calculation I have set up how much money the band gets paid at the end of the night.
I'm sure there is a way to do it but I'm to dumb to figure it out. Any help would be greatly approached and hopefully I explained my situation clearly.
Thanks again.
Daniel Wood
03 April, 2011
Hi Jon, thanks for your comments. Flick me an e-mail and I'll see what I can do to help, I may need to ask a few more questions about your solution, cheers.
Jon
03 April, 2011
Well I have some good news. Your post consumed me to the point where I did plenty of research and actually managed to pull this off myself (pats self on the back). WIth a combination of your post, my Filemaker Pro Missing Manual and some filemaker forum posts I was able to complete my goal.
I ended up using an If function nested in a Case function to achieve my weird setup.
Don't worry though, I'm sure there are many other advanced stuff I have yet to figure out. Thanks for the blog and I might request your assistance in the future. Thanks for the quick reply.
Cheers.
Kim
28 April, 2011
Thank you for this Daniel! One question, why do you need another occurrence of everything for the portal example? And is this extra occurrence set up in the exact same way as the one you walk through on the example?
Thank you!
Kim
Daniel Wood
28 April, 2011
Hi Kim,
The reason why the portal example requires additional table occurrences which are different to the ones used in the first example, is all to do with context. In the first example, the value lists are being used on the layouts context. The sport category/name/equipment fields are all direct on the layout.
However, in the portal example, the fields are now in a portal which is a different table occurrence. As such, if we used the original value lists from the first example, it simply isn't going to work
If you have a look at how the value lists are setup for the portal situation, you'll notice that for each, the "include only related values starting from" option is set to the table occurrence of the portal, whereas in the first situation it is set on the layouts table occurrence.
I'm probably not making this any clearer, and it is a little difficult to explain. In the first example, the context that the value lists are populated through is that of the layouts main context. So when the record changes, the value lists change because the source/left hand side of the relationship is changing.
In the portal case, the layouts record is not actually changing, but it is the portal rows themselves which are the things that are changing. If we used the value lists here from the first example, the values in those value lists would never change, because the value lists are still evaluating from the context of the layout, not the portal. In order for the value lists to work properly in a portal, they must be evaluated from the context of the portal, and obtain related values starting from that portals table occurrence.
Now, to put that all together, consider if you wanted to try and use the existing table occurrences that the first set of value lists are based on, simply by duplicating those value lists and changing the context they evaluate from. Looking at the sport names value list for example, the value list would begin from the portal context, go through the layouts context, and then to the sport name table occurrence:
Home to Home for Portal Example Home to Sport Equipment for Sport Names
If we actually tried to evaluate this, all portal records are going to relate back to the same home record because this is a many to one relationship going backwards to the main table occurrence like this. From there, it continues traversing the relationship from the Home record (1 record for all portal rows) to sport names.... basically the end result is every portal rows sport names value list will end up being exactly the same and not changing on a portal row by portal row basis.
have I made this even more confusing now? In short - the whole thing is a matter of context - what context the value lists begin evaluating from.
Robert Moran
08 June, 2011
Great site. Daniel has helped me before on numerous occasions on another FMPro environment and no doubt, I will be asking more questions as FM is an ocean of an app most people are unaware of. Also, I too am an avid cyclist of the road variety. Awesome sport my son turned me onto over 20 years ago. :)
Paulo Felix
05 October, 2011
Many thanks for this site. I'm not a professional FileMaker developer but I love to build solutions based on this great software for personal use and limited distribution among my friends and colleagues. This blog helped me a lot.
Something to say?