# Incorrect value when passing UDT value to template **URL:** \ **Category:** Ignition\ **Tags:** ignition80\ **Created:** [February 2, 2021, 2:24am UTC](https://forum.inductiveautomation.com/t/incorrect-value-when-passing-udt-value-to-template/42859 "2021-02-02T02:24:42Z")\ **Posts on this page:** 1\ **Showing post:** 2
**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:** [February 2, 2021, 3:19am UTC](https://forum.inductiveautomation.com/t/incorrect-value-when-passing-udt-value-to-template/42859/2 "2021-02-02T03:19:51Z")
Sounds like a bug, but I personally would never use a UDT type parameter. I would always pass in the path to the UDT into the template (I split these and pass in the DeviceParentPath and DeviceName, then combine into DeviceTagPath in the template). Then just indirectly bind using the DeviceTagPath > [@To UDT or not to UDT. That is the question](http://forum.inductiveautomation.com/t/to-udt-or-not-to-udt-that-is-the-question/32703/15): > > at a glance, it’s not possible to see by looking at a component’s properties which UDT instance has been bound to a UDT type property. E.g. in the screenshot below, I have no idea which Tower UDT is bound, I have to click on the binding to find out. It’s also far slower to populate template parameters than simply modifying a parameter string value. I tend to use 2 parameters: DeviceParentPath and DeviceName, then combine these together in an internal parameter DeviceTagPath, which also aids in… --- _[View the full topic](https://forum.inductiveautomation.com/t/incorrect-value-when-passing-udt-value-to-template/42859)._