# Slow Expression Tags

**URL:** <https://forum.inductiveautomation.com/t/slow-expression-tags/99527>\
**Category:** Ignition\
**Tags:** ignition81\
**Created:** [December 6, 2024, 3:13pm UTC](https://forum.inductiveautomation.com/t/slow-expression-tags/99527 "2024-12-06T15:13:39Z")\
**Posts on this page:** 1\
**Showing post:** 16

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [February 23, 2026, 1:52am UTC](https://forum.inductiveautomation.com/t/slow-expression-tags/99527/16 "2026-02-23T01:52:38Z")

</div>

> [@nminchin](#):
>
> slightly different status enums

I'd call that design error #1.

> [@nminchin](#):
>
> Then your UI becomes detached from the raw values of the valve tags

Until you need a second or third language, and you are screwed.

And you are still processing string lookups for many tags that aren't being watched.

For such a poorly designed project, I would construct a **shared** document tag with two layers of keys--outer enum "type" and inner state value to lookup. I would ensure the result strings were unique translation keys. Then any tag value that needs lookup and translation can just have custom tag property indicating the enum "type" for lookup.

UDTs stay lean. Lookup values are centralized. No excess computation is performed.

---

_[View the full topic](https://forum.inductiveautomation.com/t/slow-expression-tags/99527)._