# Expression Input on a Map Transform **URL:** \ **Category:** Ignition\ **Tags:** ignition83, perspective\ **Created:** [March 16, 2026, 7:13pm UTC](https://forum.inductiveautomation.com/t/expression-input-on-a-map-transform/114508 "2026-03-16T19:13:58Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![nferrin](https://avatars.discourse-cdn.com/v4/letter/n/e95f7d/32.png) [@nferrin](https://forum.inductiveautomation.com/u/nferrin)\ **Post date:** [March 16, 2026, 7:13pm UTC](https://forum.inductiveautomation.com/t/expression-input-on-a-map-transform/114508/1 "2026-03-16T19:13:58Z")
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. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/6/0/6086400140c171edb1121ae491ec51d1e8f244b7.png) -Nathan ---
**Author:** ![dkhayes117](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/dkhayes117/32/68344_2.png) [@dkhayes117](https://forum.inductiveautomation.com/u/dkhayes117)\ **Post date:** [March 16, 2026, 7:43pm UTC](https://forum.inductiveautomation.com/t/expression-input-on-a-map-transform/114508/2 "2026-03-16T19:43:00Z")
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`. 🤔 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/2/a/2a28d34ac313f17a7ad00180470f2c8fd9348d52.png) check these threads out for more details [Transform Map Expression Not working properly - Ignition - Inductive Automation Forum](https://forum.inductiveautomation.com/t/transform-map-expression-not-working-properly/105780/3) [Expression to color/StyleClass map transform example - Ignition - Inductive Automation Forum](https://forum.inductiveautomation.com/t/expression-to-color-styleclass-map-transform-example/34814) ---
**Author:** ![dkhayes117](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/dkhayes117/32/68344_2.png) [@dkhayes117](https://forum.inductiveautomation.com/u/dkhayes117)\ **Post date:** [March 16, 2026, 8:05pm UTC](https://forum.inductiveautomation.com/t/expression-input-on-a-map-transform/114508/3 "2026-03-16T20:05:45Z")
I would probably just use a pure expression for this. ---
**Author:** ![nferrin](https://avatars.discourse-cdn.com/v4/letter/n/e95f7d/32.png) [@nferrin](https://forum.inductiveautomation.com/u/nferrin)\ **Post date:** [March 16, 2026, 8:38pm UTC](https://forum.inductiveautomation.com/t/expression-input-on-a-map-transform/114508/4 "2026-03-16T20:38:23Z")
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. ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [March 16, 2026, 9:17pm UTC](https://forum.inductiveautomation.com/t/expression-input-on-a-map-transform/114508/5 "2026-03-16T21:17:18Z")
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 ---
**Author:** ![nferrin](https://avatars.discourse-cdn.com/v4/letter/n/e95f7d/32.png) [@nferrin](https://forum.inductiveautomation.com/u/nferrin)\ **Post date:** [March 16, 2026, 9:28pm UTC](https://forum.inductiveautomation.com/t/expression-input-on-a-map-transform/114508/6 "2026-03-16T21:28:09Z")
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? ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [March 16, 2026, 10:15pm UTC](https://forum.inductiveautomation.com/t/expression-input-on-a-map-transform/114508/7 "2026-03-16T22:15:49Z")
> [@nferrin](#): > > 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`. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/4/1/41da05049ceec0a521a4f374d53cc1253fb7be71.png) And I make my input property **a literal boolean** (not a 1/0!): ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/c/a/ca8ddaa48783ea5abfdb307fa4cb7ddece9e12d4.png) I get the output color I'm expecting: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/f/1/f1b054c40a360f5b3db8336f20c93f2cbddd375d.png) ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [March 16, 2026, 11:35pm UTC](https://forum.inductiveautomation.com/t/expression-input-on-a-map-transform/114508/8 "2026-03-16T23:35:50Z")
I think a good way to think of the (il)logic of using the value within the map conditions is with a case statement: ```python 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` which is nonsensical ---
**Author:** ![Nol](https://avatars.discourse-cdn.com/v4/letter/n/8e8cbc/32.png) [@Nol](https://forum.inductiveautomation.com/u/Nol)\ **Post date:** [March 17, 2026, 7:24pm UTC](https://forum.inductiveautomation.com/t/expression-input-on-a-map-transform/114508/9 "2026-03-17T19:24:07Z")
Would be nice if there was a mix of the numerical range option and the expression option tbh. I wasted an hour once also trying to figure out how to make this work for alarm set points before just moving to an expression binding instead. We have: Value 50 - Red if it equals 50 Numerical range (,50) - Red if it's below 50 Expression {this.custom.fifty} - Red if it equals 50 Missing: Range Expression (,{this.custom.fifty}) - Red if it's below 50 ---
**Author:** ![nferrin](https://avatars.discourse-cdn.com/v4/letter/n/e95f7d/32.png) [@nferrin](https://forum.inductiveautomation.com/u/nferrin)\ **Post date:** [March 18, 2026, 1:57pm UTC](https://forum.inductiveautomation.com/t/expression-input-on-a-map-transform/114508/10 "2026-03-18T13:57:46Z")
Thanks, I’ve got it now. The resultant value of the expression is compared with the value of the referenced tag/property binding using an equals operator. Thanks for the clarification everyone. I agree with NoI that it would be useful if you could use tags in “Numeric Range” Input Type.