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

Bulk Status Transitions via Import

InfraLink Import capabilities have long supported the bulk creation and bulk update of certain data records (e.g., Case, System Element, Asset). Import functionality also now supports the bulk implementation of status transitions for both Case and System Element records. Users may import historical information for a Project already underway or efficiently status any work that may be incomplete. Additionally, this Import-Transitions feature for System Elements better aligns the InfraLink web-based user interface (UI) with existing mobile app capabilities.

It is important to note the ability to bulk transition statuses is subject to all associated workflow or life cycle restrictions. For example, if a Case Workflow requires New Cases to be Acknowledged before they can be In Progress, a direct transition from the New to In Progress status is restricted. Just as Users must perform two separate transitions (i.e., New-to-Acknowledged and Acknowledged-to-In Progress) via the UI, a bulk import must also account for both transitions. In this circumstance, the transitions should be two separate line items within the CSV import file, listed in chronological order. Please note, the Effective Time specified for each transition should reflect that chronology, as well.

Required Custom Fields - Global and/or Contract configurations often present required Custom Fields with certain status transitions. If Custom Fields are required for any of the target statuses within a bulk-transition import, those Custom Fields must be populated before the bulk import can be processed. Users should populate those fields via the user interface (UI) or a separate bulk-update import prior to attempting the import of bulk status transitions.

Permissions - Users' ability to perform bulk status transitions is restricted by the same Import Permissions that restrict bulk-create and bulk-update capabilities. These apply per record type (e.g., Case, System Element).

Import Files - Bulk implementation of status transitions requires the import of properly formatted CSV (comma separated values) file.  See the tables below for details specific to Case and System Element record types.

Case Bulk Status Transitions Import File

System Element Bulk Status Transitions Import File

What You Will See in the User Interface:

• The All Cases, Work Packages, and Issue Monitor views now offer the Transitions option within the Import drop-down menu.
  • Selecting Import → Transitions will open the Import Case Transitions form.
• The Device/Equipment List view now offers a Transitions option within the Import → System Elements drop-down menu options.
  • Selecting Import → System Elements → Transitions will open the Import System Element Transitions form.
• The Import Case Transitions form and the Import System Element Transitions form prompt Users to:
  • Select import (CSV) file;
  • Enter a Default Effective Time for all CSV fields that do not have one specified within the import file; and
  • Enter a Default Comment which will display in the Updates section of each Case or System Element transitioned.

Bulk Completion of Device Tasks via Import

InfraLink uses Device Tasks to manage and track the progress of production processes on System Elements. A System Element Life Cycle includes a set of statuses and allowed transitions between those statuses. One or more Tasks may relate to a particular status within that life cycle and must be completed in order to transition to that status. Device Tasks may be created by the Device Task Generator based on Work Package Template definitions or, depending on configuration, created manually by the User.

A single InfraLink project may have tens of thousands of unique Device Tasks, numerous parties responsible for statusing those Tasks, and a variety of documents to be complete across those Tasks.

To increase the efficiency and accuracy of completing Device Tasks, InfraLink now allows Users to bulk complete Open and In Progress Device Tasks while simultaneously uploading any associated documentation (i.e., PDF Work Forms).  Please note, a PDF Work Form uploaded via this functionality will replace any previously uploaded Work Form associated with that Task.

Zip Import File - To bulk complete Device Tasks, Users must prepare and import a single ZIP file, containing

• Required “Import File List.csv" file
• Any applicable PDF files. 
  • Note: The ZIP archive file may contain folders and subfolders.

The Import File List.csv must include the six (6) columns below, with the same name and left to right ordering, although not all rows will have a value for each column.

Task Update and Files Bulk Import FIle

Error Checking

The below table summarizes error checking that is performed via the Import process. Reference this table to better understand inputs and what can be altered for a successful import. 

What You Will See in the User Interface:

• The All Tasks view now offers a Task Updates and Files option under the Import drop-down menu.
  • Selecting Import → Task Updates and Files will open the Import Task Updates and Files form.
• The Import Task Updates and Files form prompts Users to:
  • Upload the desired ZIP file;
  • Provide an optional Import Queue Name; and
  • Add a Default Comment which will display in the Updates section of each Task affected. 

Add Open Issue Flags to Multiple System Element Views

System Elements represent functional components of a system design. System Elements may represent the overall system, assemblies, individual components, connections between devices and even the terminations and ports for those connections. Users may access System Elements from numerous views and records within InfraLink, including System Drawings, System Hierarchy and various Work Package views.

As Users navigate System Elements in a wide variety of contexts, it is helpful to create flags when there is pertinent information about those records. To this end, four InfraLink views now flag System Elements when they are subject to pending work (e.g., problem or repair Cases in an open status). The four views include:

• Device/Equipment List
• All Scheduled Tasks
• All Tasks
• Milestone Progress Report

Open Issues is a newly available data column that can be added to any of the above views. The Open Issues data column displays a count of Open Issues associated with the listed System Element record. Where an Issue count flags pending work for a System Element, Users can easily select the System Element or Task record from the grid view and then navigate to Pending Work within the Details panel to review details of the open Issue.

What You Will See in the User Interface:

• The Device/Equipment List, All Scheduled Tasks, All Tasks and Milestone Progress Report views offer a new data column option, Open Issues. Learn how to customize your view to include this data column. 

• Once added to a grid view, the Open Issues column can be dragged and dropped to any position within the grid.
• When included within a grid view, the Open Issues column will display a number, which indicates the count of Open Issues for that System Element or for the associated System Element if it is displayed for a Task record.

Filter All Cases View by List of Case Numbers

Users must sometimes track the progress of a group of Cases, which do not share attributes that support effective filtering. Because no combination of filters successfully refined the Case grid view to just the desired records, the User was required to manually enter the Case Item # for each record into the Case # filter and click the plus ( + ) sign to add each entry. This was time consuming and impractical for large lists of Cases.

To improve the User experience, the All Cases view now supports multiple-value entry into the Case # filter, when values are copied and pasted from an Excel spreadsheet.

With this filter enhancement, Users can now refine the All Cases view to display a specific list of Case records and then save that view configuration for future access and/or export. Additionally, that Saved View can be expanded in the future by opening the view, pasting additional values into the Case# filter, applying modified filter values, and saving the updated view configuration.

Purge Case Records

New functionality allows Users to now purge Case records, as well as any associated Work Tickets, via the All Cases, Work Packages, and Issue Monitor views. This feature provides the ability to remove duplicate or erroneously created Cases. Previously, Users' only way to address such Cases was to transition them to a Canceled status. 

Purging a Case record(s) is an administrative function, which involves a two-step confirmation and is dependent on the following:

• User must have the Cases → Administrative → Delete Permission (New)
• Case must be in a status that allows deletion
  • This Business Logic setting (i.e., Allow Case Deletion) is configured per Case Status.
• Case must have no associated Tasks
• Case must have no logged Activities at the Case, Work Ticket or Task level
• Case must have no associated Invoices or Bill of Material (BOM's)

The Case purge functionality applies to Case records created manually and those automatically generated by InfraLink.

Case purging is permanent. There is no way to restore the Case or associated Work Ticket record(s) once deleted.

What You Will See in the User Interface:

• The  All Cases, Work Packages, and Issue Monitor views display a Purge widget for Users with adequate Permissions.

• When assigning Permissions to a User Role, the Cases → Administrative → Delete Permission is now presented as an option.

• The New Case Status and Edit Case Status forms now display a new Business Logic option: Allow Case Deletion. 
  • When enabled, Case records in this Status can be purged if they meet the additional criteria specified above.

• When purging a Case record(s), Users are presented with two confirmation messages to help prevent unintended record deletion:
  • Message #1: "Are you sure you want to permanently purge the _ selected entries? Note: this will also permanently purge all related entities and history. Click YES to continue."
  • Message #2: "Once deleted, the case cannot be restored. Would you like to proceed?"

User-Friendly Account Reactivation through Reactivation Policy Options

As a security measure, InfraLink User Accounts are automatically deactivated after a period of inactivity. The length of that inactivity period is defined by the instance administrator, but most instances utilize the default setting of 35 days. User Accounts may also be manually disabled by an administrator for a variety of reasons, such as a User no longer supporting a project.

Historically, to regain access to an instance, the User had to contact the instance administrator or Helpdesk to request account reactivation. With Users working a variety of shifts across a number of time zones, this process could sometimes experience delay.

Reactivation Policy per Authentication Provider

To improve the User experience, InfraLink now offers an Account Reactivation Upon Successful Authentication setting, configurable per Authentication Provider. This setting offers two options:

• Reactivate - Upon successful authentication, InfraLink will automatically reactivate an Inactive account. 
• Request Reactivation (default) - Upon successful authentication, InfraLink transitions the Account to the Reactivation Request status and notifies administrators of the same.

To effectively apply the reactivation policies, InfraLink now differentiates between Automatically Deactivated and Administratively Disabled accounts. Specifically, the User Account status will be set to "Inactive" after the instance-defined period of inactivity, and the User account status will be set to "Disabled" when the account is manually disabled by an administrator.

Reactivate policy Impacts:

• For User Accounts Automatically Deactivated due to inactivity, InfraLink will automatically reactivate the account upon the User's successful authentication. 
• For User Accounts Administratively Disabled, a User's attempted login will trigger an email to instance administrators, advising of the reactivation request. With this scenario, an administrator must log in to the instance and manually approve or deny the request.

Request Reactivation Policy Impacts:

• For User Accounts Automatically Deactivated, a User's attempted login will trigger an email to instance administrators, advising of the reactivation request. With this scenario, an administrator must log in to the instance and manually approve or deny the request.
• For User Accounts Administratively Disabled, a User's attempted login will trigger an email to instance administrators, advising of the reactivation request. With this scenario, an administrator must log in to the instance and manually approve or deny the request.

What You Will See in the User Interface:

•     The Accounts grid view displays two new "User Status" filter options:
  
  • Disabled: Displays accounts that have been Administratively Disabled (not related to accounts that were auto-deactivated due to inactivity).
  • Reactivation Request: Displays accounts that were disabled that have attempted to log back in.
• The "Change Status" widget at the top of the Accounts grid view now presents the option to "Disable" an account alongside "Terminate" and "Activate" actions.

PowerDB Integration Service 

PowerDB, an equipment testing platform, is designed to manage electrical power Assets including their test results, ongoing inspections, and reliability analysis through test instrument interfaces and entity specific data forms. To streamline the planning and execution of testing activities and to improve data integrity throughout an installation and/or maintenance life cycle, InfraLink now offers integration with PowerDB.

This integration service allows Project Administrators to provision tests in PowerDB utilizing the Asset records currently maintained in InfraLink. Additionally, it allows technicians to perform tests and record results via PowerDB without the extra step of copying that data over to InfraLink.