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

System Construction and Commissioning

The release of InfraLink v3.5.33 introduces enhancements for our ongoing and widely used Task Based (production) workflows. Learn more about these enhancements below.

Estimating Work Scope

...

Previously, InfraLink allowed setting either a Hour Unit of Measurement or more technical units such as linear feet, etc to measure specifics related to Task Templates and the System Element selected. While units are helpful for understanding the total scope, hours for all tasks are needed to understand the actual headcount and manhours necessary, in addition to understanding the total scope as well as work remaining. With version 3.5.33, InfraLink now allows setting both types of units to aggregate data for a Task.

What You Will See in the User Interface:

• All Tasks: The "Est. Hours" field is now available as an optional column in the All Tasks grid view.

• Task Details Panels: The "Est. Hours" field is now present in the task details panel. 

System O&M

The release of InfraLink v3.5.33 expands the already robust set of operations and maintenance capabilities, including SLA advancements and Asset Failure monitoring. Learn more about these features, which focus on making O&M teams more responsive.

Asset Issues - Tracking Functional Failures to the Asset Record

...

While InfraLink has long tracked functional failures to the impacted System Element(s), this capability is expanding to capture and report failure data down to the then-deployed Asset. This level of reporting will provide more meaningful and actionable data to system owners, as failure data can be tracked to specific device makes and models.

Functional failures will continue to be defined by Issue Type, and the determination as to whether the functional failure was actually caused by failure of the deployed Asset will be determined by the selected Cause. This helps ensure that non-Asset-related causes, such as installation error or external forces, are not erroneously logged as failures of the physical asset, or "Asset Issues".

For a Case record to result in the capture of an Asset Issue, the Issue Type must be classified as a Functional Failure, and the Problem Cause must be of the Internal category.

When a corrective maintenance Case is performed and the selected Cause confirms a failure of the deployed Asset, the following information will be extracted from that Case record and logged as an Asset failure:

• Asset identification (i.e., Asset Tag, Make, Model, and Serial #)
• Date-time occurred (from Issue)
• Date-time resolved (from-Issue)
• Total Downtime
• System Element Type (at the time of issue)
• System Element (at the time of issue)
• Location (at the time of issue)
• Asset Service time at the time of issue
• Whether the asset was replaced to resolve the issue (Y/N) - this should be set to Y if the asset was uninstalled between the issue occurred and the issue resolved date/times
• Link to case

What You Will See in the User Interface:

• The new Asset Issues grid view is accessible from the Main Menu, under the Materials Management stack.
• The Asset Issues view allows users to run a scan of Problem Cases
• Enhancements to the existing "Issue Types" grid view.
  • Asset Issues section
  • Parents field in details panel
• The New/Edit Problem Cause forms present a Category field, which allows the Administrator to select the appropriate context for the Problem Cause. Internal is the only Problem Cause Category that triggers the capture of Asset failures records.
  • Problem Cause Categories options include:
    • No Problem - No problem found. Repair is not required.
    • External - Environmental factors, external infrastructure, or parties not involved in installation, operation, or use.
    • Operation - Improper or unauthorized operation or use
    • Installation - Incorrect initial physical installation or/and configuration
    • Internal - Hardware or/and software failure intrinsic to the item. Affects asset failure and reliability statistics.

Track SLA Compliance with Improved Handling Metric Capabilities

...

InfraLink supports numerous programs with contract-defined Service Level Agreements (SLA). These SLA define performance criteria for any number of work execution milestones, such as acknowledge time, on-site time and resolution time. Teams have long relied on InfraLink Handling Metrics to track compliance with such requirements, as the application tracks work (i.e., "Case") progression against various SLA criteria defined per Contract and Priority. 

InfraLink has improved the user experience by implementing a combination of user interface and backend improvements to better communicate performance against the defined targets. First, InfraLink Case grid views now display the Handling Metric Status (e.g., Running, Paused, etc.), letting responsible parties know if performance time is presently accruing. Additionally, the application now calculates and recalculates all Handling Metrics when the Case is created or changes status and when the Recalculate Metrics option is manually invoked.

The pre-calculated and persisted SLA targets will allow for effective and efficient presentation, sorting, and filtering of cases based on their SLA performance, even when the metrics are running.

What You Will See in the User Interface:

Case grid views now offer Handling Metric Status columns, which indicate the status of the Handling Metric counter, based on the Case's then-current status:

• Running - The Handling Metric counter includes time in the current status.
• Paused - The Handling Metric counter excludes time in the current status.
• Stopped - The Handling Metric counter excludes time in the current status, and the performance threshold/milestone has been met.
• Blank (N/A) - The Handling Metric does not apply to the Case.

General Scalability and Usability

The release of InfraLink v3.5.33 expands on current access management functionality. Learn more about these features below.

Assign Default Roles Per Authentication Provider

...

As Instances and the number of active Users (both internal and external) grow, responsibilities for the management of User Roles and Permissions become expansive. Traditionally, an Instance Administrator managed all Role assignments from the Accounts grid view, and Roles assignments were based on User account descriptions or affiliations. Our newest release introduces the option to set default Roles assignments based on an account's Authentication Provider. Default Roles can include both Contract- and Global-level Roles. It is important to note, once configured, default Roles will be applied only to administrator-approved account requests. 

What You Will See in the User Interface:

• Navigating to the Authentication Providers grid view (Configure → Authentication Providers) will display the currently configured Authentication Providers. 
• Within the Authentication Provider Details Panel, a section for "Roles" will be present allowing Admins to select which Global and/or Contract default roles to assign to any newly activated accounts.