This is a critical feature to enable broader use of AF templates as well as ensure consistency of template-based elements. In the current implementation, the AF attribute can deviate from the template and yet have the green template symbol next to it.
Can I get more clarifications on your needs? By necessity, some templated element attributes should be different from one instance to another. For example, let's say you have a motor with a PI Point for the motor voltage. Each instance from this motor template would have a different PI Point representing each motor's voltage measurement. Therefore, the attribute for the voltage will be different. This is what the substitution parameters are used for. Now getting back to this idea, are you looking for some visual indication that a PI Point attribute has deviated from the template substitution parameters?
Stephen, yes I understand the need and benefit of being able to deviate from the template, the point is highlighting when the attribute configuration deviates from the template. With your example, I would design the template such that attribute(s) in the motor template can be used to store variables used in the substitution string for the tag path. This way the configuration of the voltage measurement attribute is the exact same across all motors, even though the tag name is different (with tag Motor-12:Voltage, I'd store the Motor-12 in an attribute 'AssetId' with a value manually entered as Motor-12). In general, I'd consider deviations from the template as areas where the template/tags can be improved for better standardization, making it important that these deviations are visible to the users, instead of hiding it until a user reset the element to the template which will break any changes made.
I can change an attribute from a PIPoint reference to and it will still show the green template box. Visually it looks like the attribute is still following the template when it is not exactly. You don't know whether it is or not without checking the template or by resetting it to template.
Sometimes the tag names are structured to allow for parameter substitution in the data reference but sometimes that doesn't work out and the template's data reference will just be "Enter Tag Name". So i get the point of the data reference being changed with it still adhering to the intent of the template.
However even in scenarios where parameter substitutions are used. I've had plenty of occurrences where i have had to change the data reference (for example from ..%Attribute%.UFL... to ..%Attribute%-UFL...) but this change was not carried through the attributes where the template is applied and those attributes still show like they are part of the template. The difference is only noticed on careful inspection or by hitting 'reset to template'
It seems like there should be a middle ground. Green box for an attribute following the template EXACTLY. No box for attribute that exist outside the template. And then something like an orange box for an attribute that is part of the template but has had some small things changed about (different data reference for example)
In addition to visually highlighting attributes, we would like to see PI builder or another tool support querying for this information. For example, if we have Template A I'd like to identify all instances on Template A that are not relying on the templated values.
