# Read Active Pipeline value from a tag's config using script

**URL:** <https://forum.inductiveautomation.com/t/read-active-pipeline-value-from-a-tags-config-using-script/111840>\
**Category:** Ignition\
**Tags:** perspective\
**Created:** [October 30, 2025, 8:44pm UTC](https://forum.inductiveautomation.com/t/read-active-pipeline-value-from-a-tags-config-using-script/111840 "2025-10-30T20:44:14Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![arun1](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/arun1/32/79753_2.png) [@arun1](https://forum.inductiveautomation.com/u/arun1)\
**Post date:** [October 30, 2025, 8:44pm UTC](https://forum.inductiveautomation.com/t/read-active-pipeline-value-from-a-tags-config-using-script/111840/1 "2025-10-30T20:44:14Z")

</div>

I am trying to read the configured Active Pipeline for few tags and possibly change it by using a script so that I don’t have to do it manually one-by-one. These tags are UDT instances and have alarms configured. The Active Pipeline may or may not be default values (set in UDT). I tried this but it is returning ‘null’:

```python
system.tag.readBlocking(["[default]Site2/FIT302/oHiAlarm/Alarms/High Alarm.Active Pipeline"])

```

---

<div class="post-metadata">

**Author:** ![ryan.white](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ryan.white/32/73193_2.png) [@ryan.white](https://forum.inductiveautomation.com/u/ryan.white)\
**Post date:** [October 30, 2025, 8:52pm UTC](https://forum.inductiveautomation.com/t/read-active-pipeline-value-from-a-tags-config-using-script/111840/2 "2025-10-30T20:52:46Z")

</div>

Have you confirmed that the tag at the path you are showing has a configured pipeline for that alarm? Does it show a value if you navigate to that tag property in the tag browser?

If you are trying to read and set configuration on a tag consider using [`system.tag.getConfiguration`](https://www.docs.inductiveautomation.com/docs/8.1/appendix/scripting-functions/system-tag/system-tag-getConfiguration) and [`system.tag.configure`](https://www.docs.inductiveautomation.com/docs/8.1/appendix/scripting-functions/system-tag/system-tag-configure).

> **[Tag Alarm Properties | Ignition User Manual](https://www.docs.inductiveautomation.com/docs/8.1/platform/tags/tag-properties/tag-alarm-properties#alarms-in-scripting)**
>
> In 8.1.17, the Tag Editor was redesigned to improve usability. The new Tag Editor now requires fewer clicks and keeps relevant tag information visible while modifying bindings, alarms, and event scripts.

---

<div class="post-metadata">

**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:** [October 30, 2025, 10:50pm UTC](https://forum.inductiveautomation.com/t/read-active-pipeline-value-from-a-tags-config-using-script/111840/3 "2025-10-30T22:50:54Z")

</div>

> [@ryan.white](#):
>
> using [`system.tag.getConfiguration`](https://www.docs.inductiveautomation.com/docs/8.1/appendix/scripting-functions/system-tag/system-tag-getConfiguration) and [`system.tag.configure`](https://www.docs.inductiveautomation.com/docs/8.1/appendix/scripting-functions/system-tag/system-tag-configure).

Just always be aware when using `system.tag.getConfiguration` on UDT instances that it returns not just local configuration to the instance (eg what you get when you copy JSON), but all of the overridden props from the UDT definition as well. If you were to use this with `system.tag.configure`, you would then set prop overrides for all of this at the instance level as well, defeating some of the purpose of using a template (UDT). `system.tag.configure` however can be used to write only selected configuration using the merge option in its args

> [@Ignition Extensions - Convenience utilities for advanced users](https://forum.inductiveautomation.com/t/ignition-extensions-convenience-utilities-for-advanced-users/64615/32):
>
> Is it possible to "fix" this one up as well? I'm sure I had an idea somewhere, but my suggestion was to add an argument into the system.tag.getConfiguration function to return only the config stored on the tags themselves, not from parent settings such as non-defaults configured in the UDT definition. E.g. an arg to return exactly the properties that copying the JSON of a tag returns\*. Otherwise, if you use system.tag.configure with the results from getConfiguration which contains UDT instanc…