...
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:
...
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 |
| Note | ||
|---|---|---|
| ||
Functionality is currently limited to Device Tasks. Similar capabilities for PM Tasks may become available with a future release. |
...
| Gliffy Diagram | ||||||
|---|---|---|---|---|---|---|
|
Add Open Issue Flags to Multiple System Element Views
...
- Once added to a grid view, the Open Issues comun 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.
...
Gliffy Diagram macroId 95cc7173-1bd7-4fb6-9838-44a03e1b01f9 name Open Issues Flagged in View pagePin 1
Filter All Cases View by List of Case Numbers
...
| Gliffy Diagram | ||||||
|---|---|---|---|---|---|---|
|
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 This feature provides the ability to remove duplicate or erroneously created Cases. Previously, Users' only way to address such Cases was to transition such Cases 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:
...
| Gliffy Diagram | ||||||
|---|---|---|---|---|---|---|
|
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 two new features supporting the the timely reactivation of User Accounts:
...
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 To effectively apply the account reactivation policy, InfraLink will differentiate 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.
| Note |
|---|
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.
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
PowerDB Integration Service
...
When a User attempts to log in to an Administratively Disabled account, InfraLink will email the following message to instance administrators, "This is an automated message to inform you that the MCDEAN user account of _Insert Name_ has requested reactivation and requires review." For administrators' convenience, the email will also include a link to the instance account.
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.
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
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.
...
| Note | ||
|---|---|---|
| ||
For additional information on PowerDB integration with InfraLink, contact InfraLink SupportHelpdesk. |
| Excerpt | ||
|---|---|---|
| ||
Highlighted features 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; and PowerDB Integration Service -. |