The following information describes effective implementation practices for template and instance derivation:

Best Practice

• Derive from the Base Template First: Derive a template from the base templates before deriving any instances. An object instance that is derived from one of the base templates ($AnalogDevice, $DiscreteDevice, $FieldReference, $Switch, $UserDefined, $WinPlatform, $AppEngine, and $Area) cannot be modified at the template level in the future to add additional scripting, UDAs, and so on.
  
  Therefore, always derive a new template from the base templates, even if it is identical to the base template.
  
  When a template is derived from another template, the derived template inherits all of the characteristics of the parent template. If the parent template is modified, only the attributes and extensions that are locked will propagate to child templates.
• Propagate Security: Changes made to the security control of any attribute or extension will not propagate. If new attributes, scripts, and extension are added, they always will propagate. The derived template can then take on additional functionality.
  
  When an instance is derived from a template, changes made to the security control of an attribute will propagate, but changes made to the security for an extension will not propagate. If you deploy instances of a template and then modify the template, you will then need to re-deploy the instances. Before deploying changes, you may want to perform an upload of runtime changes. The upload overwrites the initial attribute values with current run-time data.
• Lock Attributes: Use Locking to propagate functionality when modifying a template. You can then unlock the attributes and extensions when the propagation is complete.
• Name the Object: When an instance of an object is first created, it is given a default name based on the parent template name and an incremental number (_XXX).
  
  The name should be changed to meet the naming convention established for the project. If the instance is contained by another object instance, it will also have a hierarchical name.
  
  Note The object's instance name is used by IndustrialSQL Server Historian to store historical data (not the hierarchical name).
  
  It is important to properly name the object before it is deployed. Each name can contain up to 32 characters. The object hierarchy can be up to 10 levels deep for a maximum hierarchical name of 329 characters.
  
  In the case of creating large numbers of instances from a single template, see the following section regarding Galaxy dumps and loads for a potentially faster renaming mechanism for a complex compound object.