This was in Data Designer -- I haven’t tested if I can insert a Null value in Case Expressions in Horizon Rules, but I will assume I cannot given the UIs are very similar. I’m not sure if I could have done this in Bionic (can’t remember...)

I’d definitely like to have an explicit NULL value too, but I think the workaround to this is putting a space as the custom value and it acts like NULL

I’m upvoting….and in the meantime I’ve previous tackled this with a very poor work-around.

1. Create a custom field in an object. The sole purpose of this custom field is to be a Null. No default values, no rules to populate. It literally just sits there.
2. Pull that custom field into your fetch. Then in your CASE statement, when you need the Null, you “populate” your CASE statement by pointing at that custom field.

I agree that the product could ideally do this as Sarah proposes, but if you really need it now, you’ve got a work-around.

I think the workaround to this is putting a space as the custom value and it acts like NULL

@jparker actually, in DD and Horizon Rules, it won’t accept a space as a custom value! I believe old Bionic Rules case statements might have allowed this, but it isn’t allowed in DD or HRE

That’s strange. I just double-checked and I can create a new HR and use a space as the custom value for the case expression output. Leaving it blank throws an error when I first save but having a space allows it to be saved.

Actually, I think the difference between mine working and yours not working is that I’m using a string field and you’re using a number 

@jparker ah!! Yes, you are onto something!!

Upvoted.  I was going to concat a list of Case fields.  Even if I can use a space, that will probably generate some clunky results.  Back to the (very messy) drawing board...

Absolutely agree! 
So many extra transforms could be avoided! If the output is a string, I do the case with a space as output in lieu of null,  and then a full trim to have an actual null, but this workaround only works for a string output as noted above. 
Matthew’s workaround is the way I do this if is a numeric field (btw, thank you @sarahmiracle and @matthew_lind for your help -many moons ago- via Slack about this!)
 

There are two other ideas asking for the same, can they be merged @anirbandutta ? As rules engine and DD have now the same interface, they are all asking for the same  (Bradley also noted that in the second idea)

 

Hello!

In the old rules and query builder, we could set string default values to null.

In Horizon Rules / Dynamic JO, we can’t: 

Meanwhile, a boolean can be null. 

If every field can be null including booleans (excluding GSIDs), then surely the default value for a string should be able to be null. 

This is inconsistent and somewhat illogical on top of being annoying for concat formulas. 

Please fix this!

A

Let’s do data right. Please allow us to work with null valued fields.

Especially when we have to build evaluate steps to check for null data (and that data is null).

Thank you, Matthew, smart but sad . Guess I’m going for that… MEH. MEH. MEH. MEH. MEH. 

@alizee I’m remarkably talented at “Smart but Sad”, in oh-so-many ways.

In the land of boolean nulls, smart but sad workarounds are life saviors, and those who invent them are warriors of the light.