Highlights Include: Bulk Status Transitions via Import; Bulk Completion of Device Tasks via Import; Add Open Issue Flags to Multiple System Element Views; Filter All Cases View by List of Case Numbers; Purge Case Records; User-Friendly Account Reactivation through Reactivation Policy Options; PowerDB Integration Service
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
Column Name | Details |
---|---|
UUID | If specified, the UUID is used to identify the Case. This field can be blank if the Item # is specified. |
Item # | If UUID is not specified, then the Item # is used to identify the Case. This field can be blank if the UUID is specified. |
Target Status | Required. This column denotes the Status to which the Case transitions. The target Status must be a valid target Status (i.e., correctly placed in the Case Workflow), and the Target Status Name should be entered and not the Transition Name. For example, the Transition Name might be "Acknowledge" but the Target Status name is "Acknowledged Case" so "Acknowledged Case" should be the entry in the CSV file. |
Effective Time | This column marks the Date and Time (formatted mm/dd/yyyy hh:mm:ss AM/PM) of the transition to that status. If left blank, the Default Effective Time from the "Import Transitions" upload form will be utilized. If both this field and the "Import Transitions" upload form Default Effective Time are blank, then the current Date and Time at the time of processing the CSV row will be used. Transitions can also be backdated if necessary. |
Comments | This column allows Users to add a comment for the Case transition. If blank, the Default Comment from the "Import Transitions" upload form will be utilized. If both this field and the "Import Transitions" upload form Default Comment are blank, “Case Transitioned via import” will be utilized for the transition comment. |
System Element Bulk Status Transitions Import File
Column Name | Details |
---|---|
UUID | If specified, the UUID is used to identify the System Element. This field can be blank if the Unique ID is specified. |
Unique ID | If UUID isn't specified then the Unique ID is used to identify the System Element. This field can be blank if the UUID is specified. |
Target Status | Required. This column denotes the Status to which the System Element transitions. The target Status must be a valid target Status (i.e. correctly placed in the System Element Workflow), and the Target Status Name should be entered and not the Transition Name. For example, the Transition Name might be "In Service System Element" but the Target Status name is "In Service " so "In Service " should be the entry in the CSV file. |
Effective Time | Date and time of the transition, in format mm/dd/yyyy hh:mm:ss AM/PM. By allowing a date and time to be specified, transitions can be backdated to when the work was performed. If blank, the Default Effective Time from the transition upload form will be utilized. If both this field and the form Default Effective Time are blank, then the current datetime at the time of processing the CSV row will be used. Transitions can also be backdated if necessary. |
Comments | This column allows Users to add a comment for the System Element transition. If blank, the Default Comment from the "Import Transitions" upload form will be utilized. If both this field and the "Import Transitions" upload form Default Comment are blank, “Transitioned via import” will be utilized for the transition comment. |
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
Column Name | Details |
---|---|
ID | Required The Task ID can be determined by adding the “ID” column to the All Tasks grid view. |
Name | Task Name. This is not used by the import process but is something that a Project Administrator can use to help prepare and validate the information. |
System Element | The System Element ID is not used by the import process but is something that a Project Administrator can use to help prepare and validate the information. |
Completed | The date and time a Task is completed, in the following format: mm/dd/yyyy hh:mm:ss AM/PM. This will only be utilized, if the Task (based on the ID) is in an Open or In Progress status. |
Completed By | The User who completed the Task. The User name must match exactly to their Account in InfraLink and they must have the permission to complete the Task. This will only be utilized, if the Task (based on the ID) is in an Open or In Progress status. |
File | File to attach/replace to the Task. This will be the file name (including extension) of the file in the prepared ZIP file. Files can only be uploaded to Tasks configured to have a work form. |
Comments | Comment for the Task Update. If none specified, the comment from the “Update Comment” in the "Import Task Updates and Files" upload form will be utilized. |
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.
Task Status | Task Requires Work Form | Work Form in CSV | Completion Info in CSV | Result |
---|---|---|---|---|
Open | Yes | Yes | Yes | Validate and Process |
Open | Yes | Yes | No | Error - Must complete Task to upload Work Form |
Open | Yes | No | Yes | Error - Task completion requires a Work Form |
Open | Yes | No | No | Error - No completion data or Work Form present |
Open | No | Yes | Yes | Error - Task not configured for a Work Form |
Open | No | Yes | No | Error - Task not configured for a Work Form |
Open | No | No | Yes | Error - Validate and Process |
Open | No | No | No | Error - No completion data or Work Form present |
In progress | Yes | Yes | Yes | Error - Cannot attach Work Form to in progress Tasks |
In progress | Yes | Yes | No | Error - Cannot attach Work Form to in progress Tasks |
In progress | Yes | No | Yes | Error - Task completion requires a Work Form |
In progress | Yes | No | No | Error - No completion data or Work Form present |
In progress | No | Yes | Yes | Error - Task not configured for a Work Form |
In progress | No | Yes | No | Error - Task not configured for a Work Form |
In progress | No | No | Yes | Validate and Process |
In progress | No | No | No | Error - No completion data or Work Form present |
Completed | Yes | Yes | N/A | (1) If form previously loaded, update form (2) Otherwise the Task was completed in InfraLink and the form filled out in InfraLink, therefore, Error - Work Form cannot be updated |
Completed | Yes | No | N/A | Silently skipped |
Completed | No | Yes | N/A | Error - Task not configured for a Work Form |
Completed | No | No | N/A | Silently skipped |
Bulk Completion Limited to Device Tasks at Present
Functionality is currently limited to Device Tasks. Similar capabilities for PM Tasks may become available with a future release.
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.
Reactivation policy settings are not configurable from the User Interface (UI). Policy changes must be implemented at the database and require support from your InfraLink Operations Team.
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.
Learn More
For additional information on PowerDB integration with InfraLink, contact InfraLink Support.