With the most recent release of Infralink/IMMS (v.3.5.28), we are happy to offer the following new features and functionality.

System Element Configuration Templates

InfraLink System Elements represent the functional decomposition of the System being installed or under maintenance and are typically reflected in the System design. Each System Element has a specific function and Location and falls under a defined System Element Type. The parent-child relationship between System Elements establishes the System Hierarchy. Within a system, instances of a parent System Element and its respective child System Elements (e.g., assemblies) are often consistent across the design and numerous installation locations.

To expedite Contract set up within InfraLink, the application now offers System Element Configuration Templates. These templates are initiated at the System Element Type which represents the desired parent System Element, and they support the automated creation of child System Elements. When a System Element is created from that Configuration Template and transitions to the target status, the child System Elements are automatically created based on the Configuration Template definitions, reducing the administrative burden associated with device creation.

The automatic creation of child System Elements can occur at any status within the parent System Element's Life Cycle. For example, they could be created immediately, at the default initial status, or they could be created with a transition to a subsequent status. The timing for instantiation is defined by the Instance Administrator when configuring the associated status.

What You Will See in the User Interface:

• The details panel for System Element Types now includes an Add Configuration Template widget in the top right corner, which opens the <<System Element Type>> Configuration Template form.

  • Once a Configuration Template is added to a System Element Type, the associated details panel will then display a Remove Configuration Template widget in the top right corner, and a Configuration Template section will summarize the child System Elements.

• The <<System Element Type>> Configuration Template form allows users to add the System Element Types which represent the child elements.
  • Child System Element Types must be added to the form one at a time.
    • More than one of the same System Element Type can be added if the configuration includes more than one child component of that type.
  • For each added component, the User can define the naming pattern and provide a description.
  • Once added, the System Element Types can be dragged and dropped within the form to represent parent-child relationships between those components.
  • Tool Tips within the template configuration form inform User selections.
• When child System Elements are automatically created from the Configuration Template, the Updates section of the System Element Details panel will include a summary of the automated record(s) creation.

Notification Banners

InfraLink now supports instance-wide Notification Banners. These administrator-defined messages are displayed just below the top-level navigation bar, advising users of information or warnings related to the project/program or the InfraLink instance.

More than one Notification Banner may be active at any given time. InfraLink will rotate the banner display at a set interval. Banners are ordered by the creation timestamp, and displayed in descending order (i.e., the most recently created banner is displayed first).  

Once Users have read the message, they can remove the notification by clicking the "X" to the right of the banner. This action is logged as the Users' acknowledgement.

When configuring a Notification Banner via the New Notification Banner form, the administrator must define the banner message, type of notification (i.e., info or warning), banner status (i.e., inactive or active), date and time the banner will start displaying and date and time the banner will stop displaying. Because administrators configure the banner duration, there is no need to manually disable or remove outdated messages.

What You Will See in the User Interface:

• Active Notification Banners are displayed below the top-level navigation bar.
• An "X" to the far right side of the banner allows Users to remove the notification.
• The Configure drop-down menu now includes a Notification Banners option, which opens the Notification Banners grid view.
  • The Notification Banners grid view allows administrators to view all Notification Banners and filter those records by various attributes, including notification type, status and banner display dates.
  • Clicking the New button, atop the Notification Banners grid view, opens the New Notification Banner form.
  • Selecting a record from within the Notification Banners grid view opens the corresponding Notification Banner Details panel. 
  • Notification Banner Details panel includes an Acknowledged Users section, which lists all Users who have acknowledged the Notification Banner, as well as the date and time the acknowledgement occurred.

Work Ticket Owner Permissions

With an expansion of Owner Permissions, like those recently released for Case records, Work Tickets now support -All and -Own Permissions. Formerly, User Roles could include "Read" and "Update" Permissions for Work Tickets. Now, Work Ticket Permissions offer:

• Read All - This Permission mirrors the previous "Read" Permission, allowing the User to see all Work Tickets for the assigned Contract(s).
• Read Own - This Permission allows Users to see only those Work Tickets they created or those to which they are assigned.
• Update All - This Permission mirrors the previous "Update" Permission, allowing the User to update all Work Tickets for the assigned Contract(s).
• Update Own - This Permission allows Users to update only those Work Tickets they created or those to which they are assigned.

What You Will See in the User Interface:

When assigning Work Ticket Permissions to a User Role, you will now see two Read Permission options (i.e., Read All and Read Own) and two Update Permission options (i.e., Update All and Update Own).

External Case Number Settings Expanded 

External Case Numbers, represented in free form text fields, associate InfraLink Cases to record numbers from a Client/Customer system. External Case Number behavior is configured at the Contract level and now includes options such as Not Available, Optional, Optional Unique, Required, and Required Unique. Enforcing uniqueness across a Contract's External Case Number values will reduce duplication of those entries, increase efficiency across systems, and increase validation efforts to ensure that what's represented in InfraLink is then represented in the client/customer system. 

What You Will See in the User Interface:

• External Case Numbers, in the General Contract Properties section of Contract configuration, will display five options: 
  • Not Available - External Case Numbers are not applicable for this Contract and will not be available for Case management.
  • Optional - External Case Numbers are optional for this Contract and will be available for Case management. 
  • Optional Unique - External Case Numbers are optional for this Contract but must be unique across all Cases created. Duplicate values are not allowed and result in an error message, which identifies the Case record associated with the External Case Number. 
  • Required - External Case Numbers are required for any Case creation or edit. 
  • Required Unique - External Case Numbers are required for any Case creation or edit. Duplicate values are not allowed and result in an error message, which identifies the Case record associated with the External Case Number.