The Service & incidents module allows the management of various types of tasks. Which types are available to a user depends on their role settings. The key types are described on this page, but for example the Damage report has a dedicated page.

An incident or (potential) problem can be assigned to someone in your own organization or to another organization. If you assign to another organization, you cannot specify the user – that has to be done by the assigned organization (if desired). Once an assignee is filled in and the task is saved, the assignee will receive an email stating the creating of the task and that attention to process this task is required.

Incident

An incident is a single issue in the passive network that affects more than one connection. Meaning one incident has impact on N number of connections. This can either be a network incident (cables, distribution point) or a PoP incident. A PoP incident that directly impacts the passive network and therefore is (directly) service impacting, is an telco oriented PoP incident. A non-telco PoP incident is not an issue with any of the network components in the PoP but covers anything around, on or in the PoP that is required to operate the PoP, such as back-up power (battery pack), air conditioning or a fire extinguisher. Non telco does not necessarily impacts the network services directly, but can result in an impact over time.

Incident subtypes and reason codes

When creating incidents in Gridsz, the user is able to assign a subtype and reason code in order to provide the necessary details. The currently available subtypes are:

• Network
  Incident is related to the passive network outside a PoP. This can either be any cable or distribution point.
• PoP
  Incident in or on the PoP where more details can be added by assigning a reason code (if known) to detail if this is a telco or non-telco incident.

Reason codes are configured by the PO and can either be used to open, hold or close an incident. To configure the codes the PO requires to add where to use the code (open/hold/close), the actual alphanumeric code (unique), a description, assign task type(s) and if the code is active or inactive. Configured codes are communicated through the AO and Contractor API’s.

Incident relations

Gridsz can relate service tasks that have causal relations or need to be related in order to efficiently process these tasks in bulk. Connection Incidents (1 connection), Incidents (N>1 connections) and Problems are the tasks Gridsz can link. If Connection Incidents are the cause of an Incident, those Connection Incidents can be linked to the Incident. Once the incident is resolved, all linked Connection Incidents can then be closed in bulk if required. When closing the incident the user is asked if all linked connection incidents need to be closed as well or the user can deselect all or a subset of connection incidents that require closure. Incidents that reoccur and have similar characteristics can be captured in a problem in order to investigate root causes and provide tasks to resolve a problem and its root cause(s).

Incident routing

Gridsz can route Incidents and Problems to contractor organizations within an PO cluster. Allowing the PO or its NOC to direct tasks to a specific solution party. The NOC is able to choose the contractor routing for an individual Incident or Problem upon creating the incident or after the incident is created. When creating the Incident the solution party value is empty. In case a contractor sits outside your cluster in Gridsz, the PO/NOC leaves the solution party field empty and no contractor task is created. Preventing unnecessary tasks created in Gridsz which cannot be received and handled by the solution party. The NOC will have to communicate and receive updates from the solution party by phone and/or e-mail and input these in the incident. Ensuring proper follow-up and closure of the incident(s).

Problem

A problem task arises from two or more incidents that have been assessed, share a causal relation and require further investigation into the root cause to prevent a similar incident in the future. The NOC is able to compile problem tickets with open or closed incidents. As problems are focused on preventing incidents and reducing their impact and incidents are addressed real time, expect problem tickets to mainly have linked incidents that are closed. Allowing to link incidents will enable the problem to be fed with information crucial to determine impacts and root causes.

Problem, status Potential

Gridsz can determine if there is an potential problem. The NOC is able to compile possible problems from incidents (or v.v.) and assess whether this is actually a problem or single/unrelated incident. Potential problems can be accepted, once accepted they receive the status thas is assigned as per status transition flow.

Impact notification (Informing Active Operator of customer impact)

When an incident is created, Gridsz will (depending on the network info entered) provide a list of searchcodes and DHid’s for every impacted AO. To communicate this potential impact to every AO, Gridsz creates impact_notification tasks which can be communicated through the AO API or email. The impact notification will inform the AO of basic incident details, such as:

• ID
• Type
• Sub type
• Priority
• Reason code
• Expected solution time
• Network info
• Potential impact
  • Searchcodes
  • DHids
• Comments
• Attachments

The potential impact is communicated through the AO API and also retrievable by fetching the attachment (.csv) via the AO API or receive the file by e-mail notification.

In case the network info changes or is updated, Gridsz will provide a new assessment of potential impacted searchcode and DHid’s which are subsequently communicated to the AO’s by their preferred communication method.

Impact_notifications are read only for AO’s, hence no changes can be made to its information elements such as sub type, priority, status, network info, dates, etc. The AO is allowed to place comments and/or attachments in the impact_notification in order to provide information or communication to the PO NOC.

The impact_notification follows the statuses and information of its parent task – the incident. If the incident status changes (e.g.: the incident is closed), the impact_notification tasks will be closed as well. If any information changes, e.g.: the priority, this will also be updated in the impact_notification tasks.

FTU Change

An FTU Change is an HAS related order, allowing changes to FTU’s and its location (connection status). This allows active operators to request changes which the passive operator can allow by creating the FTU change task. Depending on the required change the corresponding subtype can be chosen, which are explained below. The FTU Change is only focused on HAS information, meaning no patching is involved.

FTU Change subtypes

When creating an FTU Change in Gridsz, the user is able to assign a subtype allowing the correct changes to take place. The available subtypes are explained below:

• Construct
  The FTU Change – Construct allows an FTU_CONSTRUCT task to be created for the Contractor. As no PATCH_INSTALL is issued, this task type can typically be used when an PO is actively connecting addresses with fiber, but does not wish to patch that connection.
  • The planned FTU value is used to determine what FTU type the contractor shall place.
• Move
  The FTU Change – Move allows an FTU_MOVE task to be created for the Contractor. If an address has an active connection but, e.g. the FTU location does not meet the PO’s (technical) requirements, the FTU_MOVE allows the PO to set a new location for the FTU.
  • Current FTU location is fetched from Gridsz AC (if available)
  • When creating the task, a new connection status (location) can be selected for the FTU.
  • When the contractor delivers the FTU_MOVE it can optionally be asked to confirm the new (planned) connection status. Or, if for some (technical) reason the initial planned connection status is not possible, to select and set the actual connection status of the FTU before delivering the task. This information is updated to the parent task. (this info is currently not updating AC)
• Replace
  The FTU Change – Replace allows an FTU_RECONSTRUCT task to be created for the Contractor. E.g. in case the PO whishes to upgrade the FTU for an newer model.
  • The current FTU type is fetched from Gridsz AC.
  • The planned FTU type is fetched from Gridsz AC (required for FTU_RECONSTRUCT)
• Remove
  The FTU Change – Remove allows an FTU_REMOVE task to be created for the Contractor. For example if buildings get demolished or renovated and the FTU needs to be removed and the fiber cable brought back to the property border, the PO can use this task.