Feature package customization
-----------------------------

Overview 
.........

This topic describes the components available for customization in Automate. 


.. rubric:: Related topics

* 
  .. raw:: latex
  
     Field Display Policies in the Core Feature Guide.

  .. raw:: html

     <a href="field-display-policies.html">Field Display Policies</a>

* 
  .. raw:: latex
  
     Configuration Templates in the Core Feature Guide.

  .. raw:: html

     <a href="concepts-config-templates.html">Configuration Templates</a>

* 
  .. raw:: latex
  
     Device Models in the Core Feature Guide.

  .. raw:: html

     <a href="overbuild-device-models.html">Device Models</a>

* 
  .. raw:: latex
  
     Menu Layouts in the Core Feature Guide.

  .. raw:: html

     <a href="concepts-menu-layout.html">Menu Layouts</a>

* 
  .. raw:: latex
  
     Dashboards in the Core Feature Guide.

  .. raw:: html

     <a href="automate-dashboards-overview.html">Dashboards</a>

* 
  .. raw:: latex
  
     Introduction to role-based access in the Core Feature Guide.

  .. raw:: html

     <a href="concepts-role-based-access.html">Introduction to role-based access</a>



Models 
''''''

Automate makes use of components called *models* that can be added and modified.

The table describes the primary types of models:

====================== ================================================================
Model Type             Description 
====================== ================================================================
Data Models            Used to capture and store data.

Device Models          These models represent components of available network devices.
====================== ================================================================


Field display policies and configuration templates 
''''''''''''''''''''''''''''''''''''''''''''''''''''

Higher level admins can use the following mechanisms for customization: 

=========================== ===========================================================================
Mechanism                   Description
=========================== ===========================================================================
Field Display Policies      Admins can use field display policies (FDPs) to define how different 
                            attributes of a form are displayed: 

                            * Visibility (hidden / visible / read-only) of attributes
                            * Field names
                            * Related help text
                            * Ordering, grouping, and layout

                            FDPs are applied to different roles using menu layouts and dashboards.

Configuration Templates     Admins can use configuration templates (CFTs) to define how values for 
                            attributes are obtained:

                            * Fixed or default values
                            * Derived from data in the system; optionally combined with input from users or 
                              Device Model events using pre-defined macros. 
                              
                            See :ref:`macros-feature`

                            CFTs are applied to different roles using menu layouts, dashboards, and 
                            pre-defined workflows.
=========================== ===========================================================================


Customization task overview 
..............................

A high level administrator can follow these high level steps for customization: 

1. Decide how an existing user input form should be customized.

   In this case, inspect the input form to identify field name, visibility, order, and default values.

#. Identify the user/s requiring a modified input form.

#. Identify the user role and menu layout associated with the relevant user/s.

#. If the menu item to be customized shows a field display policy (FDP) and configuration 
   template (CFT) associated with the item, then clone these to start their customization. 
   
   .. note:: 
      
      There is a unique constraint on the name of the clone per hierarchy level, so the same name as the 
      original can be used on another hierarchy, but a new name is needed at the same hierarchy. 

#. Create, or modify the cloned FDP and CFT according to identified requirements to create new instances 
   of these. 
   
   .. note:: 
      
      Note uniqueness constrains per hierarchy on the names of the clones.

#. Associate the newly created FDP and CFT to the menu item in the user's menu layout as specified in the 
   user role. The menu layout may be created as a new menu layout that is only available at a 
   specific hierarchy.