Help

Re: Using "!=blank()" is not returning the correct result

2988 1
cancel
Showing results for 
Search instead for 
Did you mean: 
Michael_Jenson
5 - Automation Enthusiast
5 - Automation Enthusiast

Original Formula (pic 1).png

13 Replies 13
Michael_Jenson
5 - Automation Enthusiast
5 - Automation Enthusiast

I’ve tested multiple formulas, and “=BLANK()” in conditional formulas works perfectly, but “!=BLANK()” does not work at all.

I was going to attach numerous screenshots walking through examples of this problem and how to reproduce it, but I am apparently a “New User” and am therefore limited to one screenshot - and it’s impossible to show everything necessary in one picture. Please fix this.

Ptt_Pch
8 - Airtable Astronomer
8 - Airtable Astronomer

Did you try by replacing !=Blank() by !="" ?
Like this :

IF(
	AND(
		{Form Name?}!="",
		{Form URL}!="",
		{Notification Emails}!="",
		{Submission Message?}!="",
		{Google Sheet Tie-in?}=1
	),
	'✅',
	'🚫'
)

Sometimes that’s just it … :woman_shrugging:

It’s also worth noting that I don’t think any of your “!= BLANK()” are necessary.

You can just say
IF({Form Name?},...)

If there is a value in the referenced field, it will evaluate to true, if there is no value (ie, it is blank), it will evaluate to false. No need for the superfluous “!= BLANK()”.

This works! Thanks! Still think they should get the !=BLANK() functionality working (there’s no reason it shouldn’t), but I appreciate the workaround.

Still think they should get the !=BLANK() functionality working (there’s no reason it shouldn’t), but this definitely works - I appreciate the help.

BLANK() behaves strangely in regards to text fields; I suspect internally Airtable stores an empty string differently from the way it encodes a true null value.

For instance, try this:

  1. Using a new base, define a number field, and call it {A}.
  2. Define a formula field, {B}, with this formula: IF(A!=BLANK(),1,0).
  3. You should have three empty rows with two fields defined. Enter a number in the {A} cell for row 1. {B} for row 1 should change from 0 to 1.
  4. Do the same for {A}, row 2. Now the first two {B} cells should each contain 1.
  5. Delete the value from {A}, row 2. {B}, row 2 should reset to zero.

Now, follow the same steps, only this time make {A} a single-line text field. You’ll find that deleting the value from {A}, row 2, does not reset {B}.

Tuur
10 - Mercury
10 - Mercury

:angry:

Just got bitten by this one again. Is this on the list guys?

Using the API in my case: [myDate != ‘’] works fine, [myDate != Blank()] does not and in my case returned a truckload of records that didn’t need updating.

Leah_Silber
4 - Data Explorer
4 - Data Explorer

Piping up here to be another person struggling with this. The workaround works, but I just spent so much time trying to figure out what was faulty with my logic when the answer was nothing :frowning: Please make !=blank() work—it’s a standard assumption once you know =blank() does work.

aaron_altamura
6 - Interface Innovator
6 - Interface Innovator

Chiming in with agreement here. :frowning:

Eric_Petersen
7 - App Architect
7 - App Architect

I was having similar difficulty using the BLANK() function. I was reading these community posts for help.

This simple filter shows the records where the Project Value (currency field) is empty works as expected.

Project Value Empty Filter

I assumed the following formula would work in field and present the same results:

Project Value Blank or $0.00

It did not, hence the name of the field, Project Value Blank or $0.00 as it returns 1 for $0.00 as well as empty fields.

Somehow, when I use this formula:

NOT({PROJECT VALUE}!=BLANK())

It only returns the empty or blank records as desired. Anyone want to explain this logic?

Project Value Blank

Hopefully, using the NOT() function will help others here with their use cases.

@Eric_Petersen: check Blank() & Zero problem or the link a couple of posts higher: Using "!=blank()" is not returning the correct result :winking_face:

Try:
not(field != blank())
I am curious you have a working solution @Tuur now.

Sure. As explained it the posts above. :slightly_smiling_face:

It still is an Airtable bug though.