Revit Families 401 – Data Validation

As I mentioned in a follow up comment to Revit Families 103 – Formula Basics, Revit still doesn’t allow you to do data validation on values or formulas in families or on table data.

Still, you can build some functionality into your families to ensure that a value never exceeds a specified range or create warnings for the user of your family.

Lets start with a simple example.  In the plan view below I am showing a basic table.

Lets say in this example that we never want the table’s width to be greater than 1/2 the depth.  We have a few choices.

1. Don’t do anything
2. Display an error message for the user
3. Default to another value

Don’t do Anything

By default your parameters allow the user to input any value they want.  You can set up relationships between parameters using formulas but the results are still dependent on user entered values.

When creating families it’s good practice to set up the basic types that you expect the user  will need.  This will limit the amount they need to edit the parameter values.  Understanding when to use instance versus type parameters will also limit problems in the future and make the family easier to use.

A well designed family should be clear and easily understandable by someone other than the person who made it.  Some things I look for are:

• Model geometry is hosted to reference plans and lines that have meaningful names
• Well named parameters grouped under the appropriate categories
• Parameters are assigned to the geometry in a logical sequence
• Model and dimension locks are kept to a minimum

Even in a well designed family there will be times that a user will be confused as to why a model is breaking, or there are conditions that must be met to keep the model valid in the real world that must be maintained.  For example, a manufacturer won’t make a table longer than 8 feet long.  With the default model there is no way to tell the user that 8 feet is the maximum length or provide clarification as to why the model broke when value “x” exceeded value “y”.  So what can we do?

Display an Error Message

The easiest thing to do is to give the user a message.  Start by creating a text parameter, I placed my error message in the Text category so that it’s at the top of the Family Types browser.

Back to our example of not wanting the table’s width to be greater than 1/2 the depth.  To alert the user to this we create the following formula for our new text parameter.

=if(TableWidth > (0.5 * TableDepth), “TableDepth”, “OK”)

Notice how I am mixing parameter names, numbers and text strings?  Pretty cool right?  If our table with is greater then half the table depth then the user gets the message “TableDepth”.

Of course in the real world you give a more descriptive message like “Table width can not exceed half the depth”.  But I wanted to make sure the formula fit in my screen shots.

If the Width is less than half the Depth then the user gets a simple “OK” message.

I really like this technique.  You can create nested error messages to handle different scenarios too.

=if(TableWidth > (0.5 * TableDepth), “Table is too wide”, (if(TableWidth < (2′-0″), “Table width must be greater than 2 feet”, “OK”)))

Default to Another Value

The guys in my office will point out that this option can be annoying because it overrides the value the user inputs and may cause confusion.  Sometimes inputing a value out of range will break a model completely so this method is necessary to prevent that from occuring.  I recommend using this method in conjunction with the error message to let your users know what you did when they weren’t looking.

In order to build this functionality you need to add some complexity to how your family is structured.  In the examples above the parameters were directly linked to a piece of geometry.  We need to insert some logic between what the user inputs and what the model does.  To make this work we create an additional set of parameters.

The parameters under the Dimensions category are what the user modifies however the parameters under the Analytical Model are what actually control the geometry.

Now we have some flexibility to insert control logic.  We can now assign the following formula to TableWidthActual.

=if(TableWidth > (0.5 * TableDepth), (0.5 * TableDepth), TableWidth)

This formula checks the values the user entered for TableWidth and TableDepth.  If TableWidth exceeds half the depth then the formula ignores the user entered width and defaults to half the depth.  Otherwise the formula passes the user entered width through.  (NOTE:  The formula in the image below is incorrect)

The ability to control the values your users enter is powerful.  Use it with caution, and like I said earlier, creating an error message like this is helpful.

=if(not(TableWidth = TableWidthActual), “Your width was changed because it was too big”, “OK”)

If you have any questions leave them in the comments.  Thanks Faekk for the inspiration for this article.