IPProtection

Triage: Combined

Triage: Observe combined with Triage: Diagnose gives you a full incident data collection and analysis solution which will aid your support process in the isolation of incidents and ultimately improving the Mean Time To Resolution (MTTR) for your support incidents.

The normal support process for any given registered support case can be difficult. Performing initial triage can be either time consuming or error prone. Triage from AXImprove structures the incident and collects technical and functional data appropriate to the incident.

The key point is; it is the user who initially observes the incident occurring. The user is the person best placed to describe the incident but often they are unable to provide all the information needed for the support process first time round. It can be difficult to replicate and more importantly to isolate so that the support process can then determine resolution steps for the incident.

The whole process of liaising between users and support personnel is fraught with inefficiencies. Often level 2 and level 3 support personnel will get involved where they do not need to, and there will be rounds of communication between the user and support, clarifying points, while support try to replicate and isolate the incident.

 

Triage assists the whole process by letting the user utilise the system to document everything required to make initial triage possible. Every user interaction is recorded both from the functional and technical aspect. In short, a document is created describing what the user did in the system thereby giving full user context to the incident, additionally the full execution path is recorded giving support a unique view from a system perspective on what interactions the user performed with the system.

Triage provides answers to the following questions implicitly:

1) How was the user interacting with the system and what data did they use when they recreated the incident?

2) What code was executed by the system?

3) Where does that code reside? i.e. Who does the code belong to?

Answers to these questions allow the incident to be scheduled to the most appropriate resources: a consultant when a system issue is detected, a developer or third-party in case of custom code.


 

 

You can easily see what the user was doing, what values they entered and what interactions they had, as full documentation is created as part of the incident creation

 

You can also observe what has happened and what code has been executed; the section above with a grey background has been modified in usr layer, the blue code execution trail also turns red when stepping on usr layer code.

Benefits

  • Triage will quickly categorise the incidents as belonging to Standard AX, an AX add-on, or a customer specific development, both reducing the time spent on the support call and ensuring optimum use of resources.
  • Triage will reveal the modules used, the layers, objects and code customisations down to line-by-line level resolution. This allows the best resource to be scheduled to investigate further. Having total visibility on the lines of code used, a developer can recognise the conditions, (just by looking at the branches of code visited) and instantly decide where to place the checkpoints, saving potentially hours of investigation.
  • Reduce the need to recreate the issue in a test environment or to connect to the customer's AX instance in many situations
  • User raising the support call can prepare all necessary documentation single-handedly and to a formal standard
  • Does not require the use of AX's standard 'Trace' which is too complicated for the average user.

Refer to the specific Triage: Observe and Triage: Diagnose pages for further information.


Microsoft Dynamics AX, Windows, SQL Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. All other trademarks are the property of their respective owners

 
© 2010 www.aximprove.co.uk - AXImprove| Privacy Policy | Terms of Use