Bug: Filtering on Null Values

I've found that Domo card filters are unable to filter on a null value. Example:


I have a field called Customer Group. When I filter it on null to see the data with null values, nothing shows up.

I created a beast mode called "Website Customer Group" that changes the null value to the string "Null", and when I filter on that then I can actually see the data. I'd like the ability to filter on null values without having to use this work around.


Null Filter.png

Website Customer Group.png

Beast Mode Filter.png



44 votes

· Last Updated


  • @SamEich Thanks for this feedback. My team and I have discussed Null values in filter box before and are looking at solutions for this request. 



  • Yes.... this is something I deal with.... I would love this feature to be aproved. 



  •  @fsalinas another one that needs your vote please.



  • As I said to my customer success manager, this is absolutely critical on 2 counts:

    1. This is a basic feature, supported in almost any other system
    2. DOMO is being deceptive because it lets you think you can filter on them by clicking the box on the empty line while this does not work

    This is apaulling user experience. This MUST be fixed.

  • Yes I need this fixed also, 

  • an excellent new feature would be to be able to write data back to a field in a table Card



  • @btm @product_John


    We need a status update on this one.



  • This is a huge issue...


    We do a lot of "not in" filtering... and when you do that, it not only excludes the records with the value you are tying to exclude, it also excludes records that have a NULL value in that field.  As mentioned above, the workaround is to create a beast mode to replace the NULL value with an actual text value... but having to remember to do that is a pain, especially as we continue to add more and more developers.


    Excluding records that you don't want to exclude... without telling you they are being excluded... very bad!


    Jeff H.

  • @ckwright


    Any update on this feature request?



  • This is an endemic problem for us.

    Since we have a connector which feeds several datasets with a dynamic number of columns with dynamic datatypes, we join and present these in a MySQL dataflow, using a statement along the lines of:
        SELECT * FROM `dynamic dataset` JOIN ...

    Therefore we

    1. do not have the opportunity to map fixed columns from null to 'a new null value' (since names and number of columns is ever changing)

    2. we would anyway not know which value to choose as our 'new null value', as this would be dependent on data type: 0 for number, ' ' for text, datetimes hopefully not required!


    A main purpose of these 'dynamic columns' is for filtering down the data, therefore we are having commonplace problems filtering out Null valued columns in almost every report.


    Since we can't really solve this issue in the dataset, we are having to create beastmodes on demand (on complaint) to resolve this:
        IFNULL(`Text field with nulls`, ' ')



  • I opened a support ticket on this in June. 

    This was the response I got back


    Screen Shot 2018-07-26 at 11.12.49 AM.png


    Which is crazy considering users have been requesting this for over two years. 


    Can we get a status update? It sounds to me like a decision has been made that this bug (it is a bug) wont be worked on.

  • bigdatadojo2000
    bigdatadojo2000 St. George, Utah 🟠

    I'm really going to have to agree with James and Chris here. This is a huge issue as we have little insight into when data is unintentionally excluded. Many reports have a dozen filters, so this would require writing beast modes to include null values for each of these filters across our thousands of cards. We are currently handling on a case-by-case (complaint) basis and our end-users are libid that they can't trust their reports.

  • This bug is 3 years old and it is really frustrating that I have to make work arounds. Is this on any roadmap to be fixed?

  • As the MajorDomo at my company, I've found this to be a barrier to adoption by our users. It's too easy for less technical data consumers to get frustrated and be less likely to trust the data and/or the platform. On top of that, it's time consuming for our analysts to create a Beast Mode work around for every field we want to filter that has nulls.

  • jaeW_at_Onyx
    jaeW_at_Onyx Budapest / Portland, OR 🔴

    @MichelleH  this is well documented since the 80s.  best practices says to fill NULL in ETL with an empty string


    Jae Wilson
    Check out my 🎥 Domo Training YouTube Channel 👨‍💻

    **Say "Thanks" by clicking the ❤️ in the post that helped you.
    **Please mark the post that solves your problem by clicking on "Accept as Solution"
  • We all know the workarounds. That isn’t the issue. The issue is the very fact we need workarounds to a well-documented, 40 year old problem that everyone else has solved. 


    Using Beastmode or ETL to replace null values just isn't acceptable. Looking at one of the datasets I use frequently, I have 86 columns. I should not have to make 86 Beastmode formulas or 86 changes in ETL. And I would need to. I do not know what my customers will want to filter on some day and I want head off this conversation:


    "Hey James, the dashboard is broken. I want to find all of my contacts with no phone number so I can update their record. The filter drop-down tells me they are there, but when I select it nothing shows up."

    So I reply

    "Well, this is a fundraising dashboard,  not a contact data management dashboard so I didn't make a workaround for a problem in Domo. I'll adjust something and let you know when you can start using it like that."


    That customer now knows three things

    -Our analyst does a bad job, doesn't understand use-cases, and isn't thorough.

    -Domo is buggy. We have a bad platform.

    -They cannot trust either.


    All because they used a dashboard off-label.




    Oh hey, this thread has been open five years now! They grow up so fast.

  • @James_Thoma  You hit the nail on the head with this. Just because users CAN work around it, doesn't mean it's not something that can be improved upon in the UI.


    Plus with Domo being a self-service platform, it's much too likely that a less technical user could run a simple ETL join and not know what to do when they try to filter that data in a card. In that event, they would either A) get frustrated and give up or B) enlist an analyst's help to fix it, thus defeating the purpose of the platform being self-serve. Either way, this discourages these users from trying to create their own content and they're no longer taking advantage of one of Domo's key strengths IMHO.


    It would be great if Domo's card filters automatically treated nulls as empty strings, as suggested by @jaeW_at_Onyx, but preserved the nulls in the underlying data. That way the cards would react in a way that intuitively makes sense to a data consumer without having to reinvent the wheel.

This discussion has been closed.