# Indirection adjustment approaches for changing tag naming standards

**URL:** <https://forum.inductiveautomation.com/t/indirection-adjustment-approaches-for-changing-tag-naming-standards/116037>\
**Category:** Ignition\
**Tags:** perspective\
**Created:** [June 17, 2026, 3:24pm UTC](https://forum.inductiveautomation.com/t/indirection-adjustment-approaches-for-changing-tag-naming-standards/116037 "2026-06-17T15:24:32Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![msteele](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/msteele/32/77889_2.png) [@msteele](https://forum.inductiveautomation.com/u/msteele)\
**Post date:** [June 17, 2026, 3:24pm UTC](https://forum.inductiveautomation.com/t/indirection-adjustment-approaches-for-changing-tag-naming-standards/116037/1 "2026-06-17T15:24:32Z")

</div>

Here's sort of a general question I have as I rationalize specifications from my clients and multiple integrators in the Solar/BESS SCADA space. Any best practices or creative solutioning?

Let's say an integrator has a standard tag naming convention for their product, where a device type of `typeA` has members A1, A2, A3, etc. Obviously much more complicated than that since these facilities usually have hundreds of thousands of tags, but the concept is straightforward. Now let's say they have view `viewA` which indirects everything based on a param `tagPath=instanceOfTypeA`.

Now let's say some clients are getting much more particular about their namespace and are providing tag naming schemes for their facilities. I would therefore assume there would be a major renaming/remapping of indirected references below `tagPath=instanceOfTypeA`, a significant amount of rework, testing, and risk to maintain the same Perspective screens for a new client's tag naming specifications.

Any shortcuts to both accommodate the client's tag naming conventions while still preserving the integrator's thousands of instances of indirection in scripts and views?

---

<div class="post-metadata">

**Author:** ![msteele](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/msteele/32/77889_2.png) [@msteele](https://forum.inductiveautomation.com/u/msteele)\
**Post date:** [June 17, 2026, 3:26pm UTC](https://forum.inductiveautomation.com/t/indirection-adjustment-approaches-for-changing-tag-naming-standards/116037/2 "2026-06-17T15:26:47Z")

</div>

One idea I had was having the deployment automation write the original standard tagPaths to a custom property, and then using something like globalVarMap or a script to write a lookup table to a custom property in the root of the UDT instance. This would still require reworking every instance of indirection in scripts and views, but at least could provide a framework for easy rework from client to client. This also sounds like it would be a significant performance hit versus native indirection. But I'm hoping for something even simpler.

---

<div class="post-metadata">

**Author:** ![hunterdg](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/hunterdg/32/67774_2.png) [@hunterdg](https://forum.inductiveautomation.com/u/hunterdg)\
**Post date:** [June 18, 2026, 3:34am UTC](https://forum.inductiveautomation.com/t/indirection-adjustment-approaches-for-changing-tag-naming-standards/116037/3 "2026-06-18T03:34:31Z")

</div>

Not sure if this is helpful, but when tag path/hierarchy outliers start causing headaches, I inevitably end up reverting to `system.tag.query()` + document tag metadata at the root of each UDT - or maybe root of each “device” subfolder (there’s a difference I can’t recall at the moment) so I can stop caring about the edge cases. Just return the relevant document tag(s) meta, put it in a `page.urlParams` prop (or `pageVarMap`), then use tags() with qvAt() to get the live data (and even mutate the static “value” that system.tag.query returns)

---

<div class="post-metadata">

**Author:** ![lane.duncan](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lane.duncan/32/83700_2.png) [@lane.duncan](https://forum.inductiveautomation.com/u/lane.duncan)\
**Post date:** [June 18, 2026, 9:48am UTC](https://forum.inductiveautomation.com/t/indirection-adjustment-approaches-for-changing-tag-naming-standards/116037/4 "2026-06-18T09:48:54Z")

</div>

> [@msteele](#):
>
> write the original standard tagPaths to a custom property

I think custom tag properties might be a good path to go.

Utilize the custom tag properties with your view bindings regardless if it is a “standard” project or a “custom” project. Essentially this makes all projects “custom “ projects (as all PV/BESS is anyways).

You will need to develop a script to generate the custom tag properties. If it is a “standard” project then the script should be fairly straightforward. If it is a “custom” project then the script may require some effort.

The custom properties could look something like Feeder:”F01”, Circuit:”C01”, PCS:”PCS01”, INV:”INV01” with some sort of wildcard (NoVal) to indicate if there is no value for the custom property.

Then each top level view could have a script that runs one time to derive the usable tag paths from the custom.props. Maybe this script needs to be adjusted for custom projects, but the goal should be minimal work at this level.

The indirection in the actual bindings would simply point to the custom.props. It would not be a complex indirection. {1}:”full\path\to\tag”

Sounds like a fun challenge.