How to Find PI Tags Used in a PI Vision Display
A PI Vision display may look simple on the screen, but it can depend on dozens or even hundreds of PI Tags, AF Attributes, calculations, and other data sources behind the scenes. At some point, most PI administrators need to answer a basic question: which PI Tags are actually used in this display?
That question comes up during PI migrations, tag cleanup, troubleshooting, Asset Framework projects, and PI Vision modernization. It also matters before you rename, replace, or retire a tag because you need to know what could break downstream.
The answer depends on how the display was built. PI Vision can reference PI Points directly or use AF Attributes. If the display is asset based, you may need to trace an AF Attribute back to the underlying PI Point before you have the full dependency.
For one display, the easiest place to start is PI Vision's built-in export. For larger environments, PI Vision administration reports, display exports, or a broader dependency inventory are usually more practical.
Method 1: Export the data sources from a PI Vision display
If you only need to inspect one display, PI Vision already gives you a simple option. Open the display and use the Save As menu to export the display data as XML or CSV.
AVEVA's PI Vision documentation states that the export includes the asset attributes and PI Tags used as data sources on the display for the selected time range. The CSV export also includes the data source, timestamp, and recorded value for each item.
A basic workflow looks like this:
Open the PI Vision display.
Open the Save As menu.
Select Export as .csv or Export as .xml.
Open the exported file.
Review the data sources listed in the export.
For a quick investigation, CSV is usually the easier format to work with because you can filter the data source column, remove duplicates, and create a simple list of the sources used by that display.
The main limitation is that PI Vision displays can mix direct PI Points and AF Attributes. If the source is an AF Attribute, you may still need to inspect its data reference in Asset Framework to determine which PI Tag sits underneath it. This matters even more with asset-relative displays, where the underlying PI Point may change depending on the asset selected by the user.
Direct PI Tags and AF Attributes are different dependencies
This distinction causes a lot of confusion during PI Vision cleanup and migration projects.
A display can reference a PI Point directly:
\\PISERVER\TAG001
Or it can reference an AF Attribute:
\\AFSERVER\AFDatabase\Area\Pump-101|Discharge Pressure
That AF Attribute may then point to a PI Point in the Data Archive.
From the PI Vision user's perspective, both symbols show operational data. From a governance or migration perspective, they represent different dependency paths.
If you only need to know what data source the display references, identifying the AF Attribute may be enough. If you are trying to decide whether a PI Tag can be renamed or retired, you need to continue tracing the AF Attribute to the underlying Point.
This is also why direct tag-based displays and AF-based displays need to be treated differently during modernization work.
Method 2: Use the PI Vision Administration reports
Opening displays one at a time works until you have hundreds or thousands of them.
PI Vision administrators can use the Detailed display content information report in the PI Vision Administration site. AVEVA describes this report as a summary of display contents that can include data items, symbols, display visibility, and display ownership.
The workflow is straightforward:
Open the PI Vision Administration site.
Select Reports.
Find Detailed display content information.
Select the time range.
Choose View or Export.
This is more useful when you need an inventory of a broader PI Vision environment rather than one display.
For example, you may want to identify displays that still contain direct PI Point references before an AF migration, or find displays that depend on an older PI Data Archive before that server is retired. In those cases, the administration report gives you a much better starting point than manually opening every screen.
Method 3: Export PI Vision displays with the Display Utility
PI Vision also includes the PI Vision Display Utility for managing displays in bulk.
Current PI Vision versions support exporting displays to PDIX files, copying displays, and remapping PI Data Archive or AF data sources. AVEVA introduced offline display import and export beginning with PI Vision 2021.
This is mainly a display management and migration tool, so I would not use it as the first option if all you need is the tag list from one display. It becomes more useful when you are already working on tasks such as:
Moving displays between PI Vision environments
Migrating PI Data Archive servers
Changing AF databases
Backing up displays
Reviewing display configuration in bulk
The exported display files contain configuration information that can also support more advanced analysis. Community users have used PI Vision display exports to inspect data-source references programmatically.
For normal administration, though, it is safer to stay with supported Display Utility workflows instead of modifying PI Vision database contents directly.
Method 4: Query the PI Vision database for a broader inventory
Advanced PI administrators sometimes query the PI Vision SQL database to understand display dependencies at scale.
Community examples use PI Vision data-source tables together with display metadata to identify which displays reference which sources. This can answer both directions of the dependency question: which sources does a display use, and which displays reference a given tag?
This approach can be useful for large inventories, but it comes with an important caveat. Direct database queries rely on PI Vision's internal schema rather than a supported public API. Those structures can change between versions, so any query should be treated as a read-only administrative aid and validated carefully against the PI Vision version in use.
For a one-time investigation, that may be acceptable. For a long-term governance process, I would avoid depending heavily on undocumented database structures if a supported reporting or API-based approach is available.
What about the PI Vision API?
The PI Vision Display Management API can automate some tasks that would otherwise require the Display Utility. AVEVA has described it as a way to script display import, export, and related management operations.
Community users have also worked with exported display information to retrieve symbol data sources, including PI Tags and AF Attributes. However, finding every place a PI Tag is used across PI Vision has historically required additional processing rather than a simple built-in "where used" endpoint.
For a handful of displays, this is probably unnecessary. For a large automated inventory, it can be useful if your team is comfortable building and maintaining the tooling.
Why finding PI Vision tag usage matters
Knowing which tags feed a display is useful for much more than troubleshooting. It becomes important any time a team plans to change the source data behind an operational screen.
Imagine a PI administrator preparing to retire an old PI Data Archive. Before removing it, the team needs to know whether active PI Vision displays still reference tags on that server.
The same issue comes up when renaming tags, cleaning up duplicates, changing interfaces, moving AF databases, or restructuring Asset Framework. All of those actions can affect PI Vision displays in ways that are not obvious until something stops working.
A good inventory supports several common workflows:
PI Vision migrations
PI Tag cleanup
Data Archive retirement
AF migrations
Troubleshooting broken displays
Finding hard-coded PI Tags
Converting tag-based displays to asset-based displays
PI System governance
Downstream impact analysis before a change
This is fundamentally a lineage problem because PI Vision is a downstream consumer of operational data.
Be careful with asset-relative displays
Asset-relative PI Vision displays make the problem more complex.
A symbol may be configured against an AF Attribute instead of one fixed PI Point. When the user changes the asset context, PI Vision can resolve the same Attribute to the PI Point associated with the selected asset.
That is one of the main benefits of Asset Framework because a single display can work across many similar pumps, compressors, or other pieces of equipment. It also means that a literal list of tag names stored with the display may not tell you every PI Point that can appear on the screen.
For impact analysis, you may need to follow a path such as:
PI Vision display → AF Attribute → AF Template or Element → PI Point
This is especially important before deleting tags or restructuring an AF database.
How to find every PI Vision display that uses a PI Tag
The reverse question is just as common.
Instead of starting with a display, you may have a PI Tag and need to know every display that depends on it. This comes up frequently during tag cleanup, server retirement, migrations, and duplicate-tag projects.
For a small environment, display exports or administration reports may be enough. You can export the data and search for the Point or AF Attribute you care about.
At larger scale, you need a dependency inventory that maps:
PI Tag → AF Attribute → PI Vision display
Ideally, that same inventory should include calculations and other downstream consumers as well.
Once that dependency map exists, tag cleanup becomes much safer because teams can see where the data is used before changing or retiring the source.
How Osprey finds PI Tags and AF Attributes used by PI Vision
Osprey is designed to inventory PI Tags and AF Attributes referenced across a PI Vision environment and associate those sources with the displays that use them.
That makes it possible to answer questions in both directions:
Which PI Tags and AF Attributes does this display use?
Which PI Vision displays depend on this PI Tag?
Does the display use direct tags or AF?
Which displays could be affected if the tag changes?
Are stale or retired tags still referenced by active displays?
This is more useful than a one-time export when the environment changes frequently because the dependency information becomes part of the broader PI lineage model instead of another spreadsheet that becomes stale.
It can also support modernization work. Teams can identify displays that still use hard-coded PI Tags, understand how those tags map to assets, and prioritize which displays should move toward AF-based structures.
PI Vision tag usage checklist
Before changing or retiring an important PI Tag, check:
Is the tag referenced directly by any PI Vision displays?
Is it referenced indirectly through an AF Attribute?
Is the AF Attribute used by an asset-relative display?
Which PI Vision server contains the display?
Who owns the display?
Is the display still actively used?
Does the tag feed a PI Analysis?
Do other calculations depend on it?
Are reports, analytics, or AI applications using the same data?
What needs to be updated before the tag changes?
The more important the tag is, the more useful it is to answer these questions before making the change.
Frequently asked questions
How do I see which PI Tags are used in a PI Vision display?
For a single display, one of the easiest methods is to export the display data from PI Vision as CSV or XML. The export includes the display's PI Tags and asset attributes used as data sources.
PI Vision administrators can also use the Detailed display content information report to review data items across multiple displays.
Can I export all the tags from a PI Vision display?
Yes. PI Vision can export display data to CSV or XML. The exported information includes the display's data sources and recorded values for the selected time range.
This is useful for one display or a small number of displays, but broader inventories are usually better handled through reports or automated tooling.
Can a PI Vision display use AF Attributes instead of PI Tags?
Yes. PI Vision supports both direct PI Point references and AF data sources.
If a display references an AF Attribute and you need to know the physical PI Point underneath it, you must also inspect or resolve the Attribute's data reference.
How do I find every PI Vision display that uses a particular tag?
For small environments, export the display information and search the resulting files. PI administrators have also used read-only queries against PI Vision's internal data-source tables, although those approaches depend on internal database structures.
For larger or continuously changing environments, a lineage or dependency inventory is more practical because it maintains the relationship between tags, AF Attributes, and displays.
Can the PI Vision Administration site show display data sources?
Yes. The PI Vision Administration site includes a Detailed display content information report that can include data items, symbols, display visibility, and ownership.
The report can also be exported to CSV for broader analysis.
Why should I know which PI Tags are used in PI Vision before deleting a tag?
A tag that still feeds a PI Vision display can leave users with missing or broken data if it is renamed or retired.
The same tag may also be referenced indirectly through Asset Framework or used by calculations, reports, and other applications. Checking downstream usage before making the change reduces the chance of creating problems elsewhere.
From tag inventory to PI lineage
Finding the tags used by one PI Vision display is fairly straightforward. Maintaining that information across hundreds or thousands of displays is harder because displays, tags, and AF models change over time.
A dependency inventory gives teams a more sustainable way to manage that complexity. By connecting PI Tags, AF Attributes, analyses, and PI Vision displays, teams can see how operational data is being used before they rename, migrate, or retire it.
Osprey provides that lineage across the PI environment so teams can see which displays depend on a tag and which tags support a display without manually inspecting each screen.