FANDOM


GEMS 7.1 Edit

ITS-WSC4711 Edit

  • INSTRUCTIONS
  • PROJECT PURPOSE
Summary of Request:
Create Email Notification of Incidents Routed to Global (mis-route)
Escalation process, Send Email only after the incident has been in the global (Team Type = Global) queue for "x" minutes, where "x" is configurable, Send the email to a configurable address. The email to show as a minimum the incident details of date, time, GEMS incident number, priority, queue name, contact name, country, contact person, contact phone number.
  • PROJECT ACTIVITES/EFFORT COST ESTIMATES


  • HIGH LEVEL DESIGN
This will involve an escalation process. An email will need to be sent when an incident has been in the Global Queue for xxx period of time. Where possible the code will conform to the scoping documents ITS-WCS5384, ITS-WCS5382, ITS-WCS5259.
When the incident is first created the Customer Name Lookup Record (and/or Team, Market Name lookup records) for each Customer will contain this event within the list of Email Events and Tests in the form Event-Test. I.E.:08-xxx-72: where 08 is the Email Event, xxx= time and 01 is the Event Test
Configuration records will need to be created for determining the Team Type to check before sending an email.


When the incident is first created the Team Type to test against will be set from the lookup record using the Event Test value. The Time will also be extracted from the Email Event and stored in seconds. These stored values will be used in the escalation filter that will run every 5 minutes. If the incident matches the Team Type stored from the lookup record and the incident has been opened for more than the create time plus the stored time value and no email has yet been sent then an action record will be created and it will set a field to indicate an email was sent.
Utilize the capability as defined in the scoping document for ITS-WCS5259.
- Use lookup records to contain the following
- Team, Customer Name Market Name, Event Type, Test Values
- For OpenClose emails the values might be - Email Event (Value 1) might be “08:” - Event Test (Value 2) might be “72” - Test Values (Value 3) might be “|Global|
Once the Action record has been created a Task Code will be found and added to the action and this Task Code, 0046 or similar based on the new RFC email requirements referenced earlier, will trigger the sending of the email using existing Notify Lookup records which contain the Email addresses, Subject and the Template to use.


  • ASSOCIATED RISKS
If for some reason the new email process is not viable then this could be done as a new Rule i.e :220-xxx-yyy: where xxx is the time and yyy is the team type. The xxx and yyy values would be placed into new fields on the incident form when the rules are loaded. The escalation process would use these fields to create a new action if required. Existing Task Code 0046 would be used to get the template name and this would then get the required Notify Lookup record which has the template, subject and email addresses and send the email. The time to do this would be the same.


  • ASSUMPTIONS
I have assumed only one email will be send. If emails are to be sent every time the escalation runs and the incident has exceeded the allowable time then this will require some small coding changes.


  • INTERDEPENDENCIES


  • OUTSTANDING ISSUES AND CONCERNS
I am unsure if the fields required need to be in the body of the email or in the Subject or in both. The data required in the email comes from the incident record but the generating of the email will trigger from an action record. This will limit the template to a text template only. If HTML is required additional coding or using the nsm3_notify form proposed in the other RFC scoping documents for 7.1 will be required.

ITS-WCS5259Edit

  • INSTRUCTIONS
  • PROJECT PURPOSE
Summary of Request:
Re-configure of Email alert Notification for Fiserv Australia
Send emails on Open/Close and Change of Severity.
Open/Close Emails to be sent based on the Incident Severity
Change of Severity Upgrade emails to be sent based on the Incident Severity.
Customer requires upgrades from Minor to Major and Critical Severity only to send emails
Severity downgrades do not send emails.
Customer requires Open/Close emails where severity is Minor, Major or Critical.
  • PROJECT ACTIVITIES/EFFORT COST ESTIMATE


  • HIGH LEVEL DESIGN
The emails will need to be sent. One when the incident is opened, One when it is closed and one whenever the Severity is increased from Minor to Major, Minor to Critical or Major to Critical.
Configuration records will need to be created for determining the Severity to send on an Open/Close and the Severity change on a Severity Upgrade email.
Utilize the capability as defined in the scoping document for ITS-WCS5384.
Use lookup records to contain the following:
Team, Customer Name Market Name, Event Type, Test Values
For OpenClose emails the values might be:
Email Event (Value 1) might be “:01:02:”
Event Test (Value 2) might be “04”
Test Values (Value 3) might be “|Minor|Major|Critical|
For Severity Upgrade the values might be:
Email Event (Value 1) might be “:03:”Event Test (Value 2) might be “05”
Test Values (Value 3) might be |Major>Critical|Minor>Critical|Major>Critical| (A “%” symbol can replace the value before the “>” to signify all Severities.)


If the Customer is configured to send an email on Open/Close or Severity Upgrades, either using a current Rule, a new Rule or the process defined in the scoping document ITS-WCS5382 then before sending the email a filter guide will be called that processes the different event types. Preference is not to use existing Rules but to use the final scoping for ITS-WCS5382.
The following process should be similar to the final scoping for ITS-WCS5382. The Customer Name Lookup Record (and/or Team, Market Name lookup records) for each Customer will contain a list of Email Events and Tests in the form Event-Tests. I.E.:01-04|07|10|:02-04:03-05:. A guide is used to process each Event Test. Each Event Test Guide is bundled into a single guide. The combination of the Email Event and the Event Test will determine if the specific Event Test Filter Guide is triggered. Once triggered if any required test fails no email is sent.


  • ASSOCIATED RISKS
  • ASSUMPTIONS
  • INTERDEPENDENCIES
  • OUSTANDING ISSUES AND CONCERNS

ITS-WSC5382Edit

  • INSTRUCTIONS
  • PROJECT PURPOSE
Summary of Request:
New notification events needed
- status change
- ETA notificatioN
- suspend start/finish
- chasing/escalating, resolution validation


  • PROJECT ACTIVITIES/EFFORT COST ESTIMATES
  • HIGH LEVEL DESIGN
New Notifications are required. Currently Open, Close and Specialist Emails are sent using Rules 188 and 51.Rather than create a new Rule for each new Notification different functionality is to be used.


Task Code 0046 is used to send emails from an Action; however this functionality cannot use AR System Email Templates. Only Text Data can be used. This is because data fields in the content of the email are converted to the actual value from within the forms and not when the email is being sent. AR System Email Templates can only apply to a single form. Task Code 0046 gets data from all the forms before sending the email. The content of the email is stored in one field and cannot be stored in a template. Alcatel-Lucent requires templates as they can be in HTML format.


To resolve these issues I propose a new Form, lookup records and Task Code to initially be used for the new notifications but eventually can be used to replace all existing Email Rules. Existing Open and Close emails can be shifted to this new method. Resending an email needs to be changed to use the new form. Specialists can also be handled this way by creating an Action instead of creating an email and using the action to send the email
For all fields to have notifications there needs to be an Action Record created. Some field changes already produce tracking Actions. These needs to be checked to ensure sufficient information is provided on the Action to use Task Codes to determine if an email is to be sent. New information includes the address information from the incident.


Define a new Task Code .For this document I will use 0099 to represent the number.



If the action created matches with a Task Code Record and The Task Code is 0099 then determine if an email needs to be sent. For this functionality, see ALE_L04_send_email_configuration. There will be a parameter attached to the Task Code Number to define the Notify Template Name that is to be used to find the Email Notify Template record. E.g. 0099-templatename.
Once it has been determined that an email is to be sent get the email addresses from the action (downloaded from the incident when the action is created, or added to the action by the agent). If none exists try getting it from the incident. If still nothing then use a lookups record. If still nothing do nothing.
Get the Template to use. Use Market Name, Country Code and Template Name to find the correct template. The template comes from the Email Notify Lookup which is to be modified to contain the following:
- Team
- Customer Name
- Market Name
- Country Code
- Template Name (same name as defined in the Task Code for 0099)
- Notify Subject
- Notify Template Name (AR Systems Email Template Name)
- Notify Template
- Template Type where 0 = Use Notify Template Name only, 1 = Use Notify Template Only, 2 = Use both
(This means to process the Notify Template text and place the results within an AR Email Template. This allows you to use fields not defined on the nsm3_notify form).
Data in the Subject and Notify Template are processed to get values for field names before sending to the nsm3_notify form
Create a New Form nsm3_notify to handle the sending of the email. The new form will have a minimum of 3 Pages (Global, Incident and Action). Additional pages can be added as required for other forms such as Dispatch
Global Tab contains
- Key fields (Team, Customer Name, etc
- Address fields (To: From, CC, et
- Template fields (Notify Template Name, Notify Template, Notify Subject and Template Type
- Incident Id, Load Status (1=Loaded, 2= Do not Load
- Action Id, Load Status (1=Loaded, 2= Do Not Load
- Create date, Status (Active, Deleted), et
Incident Tab- Incident fields as per existing Rules.
Action Tab- Action fields as per existing Rules (if any
Push data to Global, Incident and or Action tabs on the nsm3_notify Form to send the email. Team, Customer Name, Market Name, Address information and templates are the minimum required
Nsm3_notify form will get data if requested from the Incident or Action (e.g. Incident Id not Null and Load Status = NULL.) Email will then be processed based on the Template Type
Change Resend capability to use the new capability and adjust rule 51 and 188 to use the new capability or shift the open/close and specialist emails to this functionality.
Create email action records to indicate an email was built for each notification that is sent.


  • ASSOCIATED RISKS
  • ASSUMPTIONS
Notification emails cannot be resent. Only Close, Open emails can be resent. Open and Close Emails will be continue to be sent directly from the incident form so as to bypass any testing.


  • INTERDEPENDENCIES
  • OUTSTANDING ISSUES AND CONCERNS

ITS-WCS5384Edit

  • INSTRUCTIONS
  • PROJECT PURPOSE
Summary of Request:


Notification events determined by NCR priority:
Before sending an email, determine if the email is to be sent. This is configurable by NCR Priority.
  • PROJECT ACTIVITIES/EFFORT COST ESTIMATES
  • HIGH LEVEL DESIGN
Create a new Lookup record to contain the test required and the test data to be used when determining if an email is to be sent.
Use a Bit pattern (0=No Test, 1= Test) to determine what tests to perform. Currently only two tests
- Market Name
- NCR Priority
Select the lookup record by Team, Customer Name and Name.
Add an additional field to the Email Notify Template to contain the name of the lookup record created in Step 1.
Load the Lookup record and perform the tests from within a guide. As new tests are added additional filters are added to the guide.
Where possible the data to test against should be pushed with the action record when it is created. If not possible then the data will be obtained from the relevant record before doing the tests. Once any required test fails no further tests are done, the guide exits, and no email is sent.


  • ASSOCIATED RISKS
  • ASSUMPTIONS
  • INTERDEPENDENCIES
  • OUTSTANDING ISSUSE AND CONCERNS

GEMS 7.2Edit

GEMS 7.3Edit

GEMS 7.4Edit