Skip to end of metadata
Go to start of metadata


If the analysis leads us to some Application related issue, then the Incident most probably depends from a wrong configuration of the Application itself or from an issue on the specific mobile platform.

We assume that before starting this troubleshoot we checked in the previous phases (ie Incident Definition and Incident Description) that the User's mobile platform is supported and that no know wrong configurations are set up in the platform itself. So we get here assuming that the Incident might be strictly related to PrivateGSM itself.

First Level

The quickest way to restore a good Application configuration is to repeat the activation, which implies to download and apply the application correct configuration as well. After the activation, let the user perform again any action which led to the incident reported. If the incident is no more present (and this behavior is consistent with the timing declared by the user in the Incident Description phase), the the Incident is closed. Else, it's better to ask the User to send the logs of the application and then escalate to the second level.

Second Level

In case of Application Incident reporting, the Second level due is to make sure we are not facing an application bug. Thus the second level priority is to perform a reproduction test so to collect the largest data amount. A side effect is to make sure this Incident is reproducible so as its resolution can be checked when discending from the third level back to the second one. If the issue is reproducible and not solved in the second level, then we need to escalate to the third level.

  • No labels