Great work team! Thanks so much for this feature, super useful, and it's great to get these Beta / Experimental features as they're developed.
Some feedback about using groups:
IMO altering the naming convention might be useful. It's nice to have granular control about which users see which features, but I'm going to try most of them, and from an admin perspective I imagine myself 6 months from now having 5 or 6 different named expirimental/beta groups. Instead of "Merged Results Beta Users" and "Custom Fields Beta Users" if the naming convention was flipped to "Beta Users - Merged Results" and "Beta Users - Custom Fields", then I could sort my groups alphabetically and those would all get sorted together.
Feedback on this specific Custom Fields feature:
I would love if we could write sql more directly, I think that would be (1) both easier to author and also (2) more powerful (edited to describe in more detail).
On (1), I'll just say that at least for me, switching back and forth between these different languages causes me some pause, I have to switch gears in my head -
"SQL Syntax" case when boolean1 then 'a' when boolean2 then 'b' else null end
"Looker Expressions" if(boolean1,'a',if(boolean2,'b',null))
On (2), I believe this feature as-is allows me to create a filtered sum, such as:
sum(case when attribute1='a' then field1 else 0 end) as filteredSum1
but if I wanted to represent something more arbitrary / complicated, like:
when attribute1='a' then field1
when attribute1='b' then field2
else 0 end) as customField
I can't do that using this feature as-is, right?
Understood that the SQL syntax is database specific, which has some downsides, but for prototyping and answering adhoc questions, this would be super useful, similar to how SQL can be defined directly when defining measures in LookML.