# How to Create Linked Symbols and Faceplates in Ignition?

**URL:** <https://forum.inductiveautomation.com/t/how-to-create-linked-symbols-and-faceplates-in-ignition/116466>\
**Category:** Ignition\
**Tags:** ignition81, scripting, vision, perspective\
**Created:** [July 20, 2026, 3:57pm UTC](https://forum.inductiveautomation.com/t/how-to-create-linked-symbols-and-faceplates-in-ignition/116466 "2026-07-20T15:57:50Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![sudhamadiwale13](https://avatars.discourse-cdn.com/v4/letter/s/f04885/32.png) [@sudhamadiwale13](https://forum.inductiveautomation.com/u/sudhamadiwale13)\
**Post date:** [July 20, 2026, 3:57pm UTC](https://forum.inductiveautomation.com/t/how-to-create-linked-symbols-and-faceplates-in-ignition/116466/1 "2026-07-20T15:57:50Z")

</div>

Hi everyone,

I am a new learner of Ignition SCADA and I'm currently exploring how to build reusable components.

I would like to learn:

- How can I create **linked symbols** (reusable graphics/components) in Ignition?
- How do I create **faceplates** for equipment such as pumps, valves, and motors?
- What is the best practice for passing tag paths and parameters to these reusable components?
- Are there any step-by-step tutorials or sample projects that explain this process?

Any guidance, documentation, or example projects would be greatly appreciated.

Thank you!

---

<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:** [July 20, 2026, 4:03pm UTC](https://forum.inductiveautomation.com/t/how-to-create-linked-symbols-and-faceplates-in-ignition/116466/2 "2026-07-20T16:03:10Z")

</div>

Best place to start is by watching the videos at Inductive University(it's free).

> **[Basic Template Video at Inductive University](https://inductiveuniversity.com/video/basic-template/8.0?r=%2Fvideo%2Fsearch%2F%3Fq%3Dtemplate%26checked_topics%3D)**
>
> Learn how to create a basic template in Ignition. You can then create multiple instances of this template throughout your project.

> **[Template – Indirect Binding Video at Inductive University](https://inductiveuniversity.com/video/template-indirect-binding/8.3?r=%2Fvideo%2Fsearch%2F%3Fq%3Dtemplate%26checked_topics%3D361%2C484%2C667)**
>
> Learn how to create templates that point indirectly to a set of Tags based on a simple parameter.

In general, creating re-usable templates comes down to using indirect bindings in the template, and having a standardized folder/UDT structure for the device type in your Ignition tags. With these done correctly, you can have a single faceplate that can be used for several models or variations of devices of the same type.

One thing to be aware of is the differences in terminology between Perspective and Vision. Vision has 'Templates' and Perspective has 'Embedded Views'. They are functionally very similar with slight differences.

---

<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:** [July 20, 2026, 4:12pm UTC](https://forum.inductiveautomation.com/t/how-to-create-linked-symbols-and-faceplates-in-ignition/116466/3 "2026-07-20T16:12:20Z")

</div>

Highly suggest every relevant view in your system take a consistent `tagPath` parameter which is the root of whatever node (device, component, system, etc.) it is intended to indirect.

I've also found it's also helpful to have views in Perspective largely match the UDT structure to the extent possible, such that if you have an instance of a device UDT=`Devices/Manufacturer/Model` it will map to a viewPath=`viewType/Manufacturer/Model`.

---

<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:** [July 21, 2026, 1:03am UTC](https://forum.inductiveautomation.com/t/how-to-create-linked-symbols-and-faceplates-in-ignition/116466/4 "2026-07-21T01:03:08Z")

</div>

> [@msteele](#):
>
> such that if you have an instance of a device UDT=`Devices/Manufacturer/Model` it will map to a viewPath=`viewType/Manufacturer/Model`.

I do things differently to this. In general, a motor from different manufacturers will have a very high percentage of the exact same tags across all of them. The only real changes are what detailed info you get back from them. I have a single template View pnid symbol for a pump and motor that is used for motors from any manufacturer, given the basic info shown on the device symbol will be the same (for me at least) e.g. status, mode, (speed if relevant), alarms active.

I also have a single popup used for all devices, not just motors/pumps, which contains the skeleton: the title/header, tab navigation bar, etc.. The contents of some of the tabs are what change, based on the UDT definition. There are fixed tabs as well for things that are common across all devices like alarms, interlocks, trends.

---

<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:** [July 21, 2026, 2:05pm UTC](https://forum.inductiveautomation.com/t/how-to-create-linked-symbols-and-faceplates-in-ignition/116466/5 "2026-07-21T14:05:25Z")

</div>

Yes that's a good approach as well - depends on the level of complexity of the nodes under tagPath.  
I'm modeling different types of power conversion stations with different electrical one lines, configurations of subinverters and inputs, etc with potentially 100+ tags per PCS. Or tracker systems that are fundamentally different from vendor to vendor. Yes, I attempt to normalize and abstract these node namespaces between vendors and models -- `/Metering/P` for a PCS will always mean the same thing -- but I found it's not worthwhile to try and standardize views between models in my industry. Another case of where Ignition architecture is fluid depending on use case.
