Am I missing something here? Regardless of the ‘alarmSetpoint’, shouldn’t the output be blue or purple, not red? Fyi, ‘alarmSetpoint’ is currently a value of 30.
-Nathan
I tested this, and it seems that with an expression mapping, {value} is not a valid identifier in the expression.
Changing {value} to {view.custom.tempF} in each expression still did not work, which I figured should work. Adding one of the expressions to the fallback value, shows that the first expression is evaluating to true. 
check these threads out for more details
Transform Map Expression Not working properly - Ignition - Inductive Automation Forum
Expression to color/StyleClass map transform example - Ignition - Inductive Automation Forum
I would probably just use a pure expression for this.
This is a simplified form of what I was trying to accomplish. There were more states (5), but I slimmed it down for troubleshooting. I though this was the best approach because I would have the color picker rather than having to specify the RGB or HSL in the expression. I could use an expression and a map transform with an intermediate integer, but that seems kludgy to me.
If you’re using these colours in more than one place, you shouldn't be using magic colours. If this is the case I would be creating style classes for them and swapping out the style class instead
The colors are only being used in 1 place on an embedded view. The embedded view is used a dozen times.
Can I even use a style class on an element of an embedded SVG?
I guess the map transform expression input is just broken then? Or am I misinterpreting something?
It's sort of broken, sort of pointless, and sort of being held wrong.
There's no special syntax inside the map transform input expression to refer to the incoming property. This appears to be by design, or at least it's been that way from the beginning, and I can see some defense of it. Remember that what you're doing here is returning an expression that itself defines a numeric value case to use in the map filter -- a fairly contrived scenario; typically the conditions for a map transform would not be dynamic, or if they were, would not be dynamic on the value passed in to the transform.
So in this case {value} is being treated as tag lookup, which basically guarantees it fails unless you have a literal tag named value at the root.
But even if that worked, in your first example you're using two expressions that return boolean conditions - true or false. Those are not numbers, so (even if the lookup worked the way you want it to) they're stored in an internal map as true and false.
Then your property is evaluated against those values. Because the stored key was not numeric, the input number is treated as an exact reference - and 123 (or whatever number) is not exactly the same as true or false from Java's perspective. Thus you hit the fallback case.
To prove that it's all "working", by some definition of working:
If I have a tag value with a value >= 50, the first case in my map transform is true -> red.
And I make my input property a literal boolean (not a 1/0!):
I get the output color I'm expecting:
I think a good way to think of the (il)logic of using the value within the map conditions is with a case statement:
case({value}
,{value}>10, 'Red'
,{value}<=10, 'Yellow'
,'Green'
)
Using the value just doesn’t make sense here. You’re essentially testing for {value} == {value}>10 and {value} == {value}<=10