The E-Mail templates which can be changed or filled in are being described here.

1) Search for the template of which you receive the requested conditions or recipients.
Pleasesettings und E-Mail templates.

There you can compare the internal templates with the template of your mail until you have found the right name.

2) Let’s assume that you have found the template of interest which has been created by the template „casenote“. Please use the search function of MsWord in order to find the location where the template „casenote“ is described. You will find the following:

• Where: SupportCase Detail, ProblemDetail
  
• When: User adds a comment
  
• Who: User of the support teams which are included in the category of the problem
  
• How: Only if the „globalSettings.sendCaseNoteMails“ are set to „true“, if the user hasn’t been deleted, if the emailNotification is set to „true“ and has the permission called „Case.SendEmail.Internal“ which has been allotted to one of the roles
  

3) The last thing to do is to interpret the found template.
The items of the template description have the meaning as follows:

• Where: describes the location of the application where it is being called up (e.g. they are the support for problem and detail forms)
• When: describes under which circumstances the template is how called (e.g. if the user always inserts a comment)
• Who: describes who has received a corresponding notification (e.g. all support team members being included in the category of the case)
• How: describes additional conditions or limitations for a template (e.g. one of the conditions is that „sendCaseNoteMails“ is being set to “true” or that the user hasn’t been deleted)

1) Template: „user.forgottenpassword“

• Wo: Login-Formular
  
• Wann: Die Email wird nur versendet, wenn der Benutzer anhand des Loginnamens gefunden wurde
  
• Wer: Benutzer mit eingegebenen Login-Namen
  
• Wie: Absender ist die defaultSenderAddress in der tbGlobalSettings, Empfänger ist die Email des Benutzers. Sprache des Templates wird anhand der Benutzer Locale gewählt. Es können nur spezielle Platzhalter benutzt werden (die Standardplatzhalter DATA: funktionieren nicht, bis auf die globalen Platzhalter @@ z.b.: [@@applicationURL]).
  

Folgende Platzhalter gibt es: {0} {1} {2} {3} Anrede (lokalisiert), Nachname, PasswortvergessenLink-Gültigkeitsdauer (in Tagen), PasswortvergessenLink-ActivationKey

<note tip>ANMERKUNG: Die Funktion kann nicht genutzt werden um gesperrte Benutzer wieder zu entsperren, sondern nur um ein neues Passwort zu vergeben.</note>

2) Template: “supportcase.poll.completed”

• Wo: CasePoll
  
• Wann: Kunde beendet Füllung von CasePoll
  
• Wer: Benutzer, die den Incident gelöst haben und die in ihrer Rolle das Recht Case.SendEmail.Internal haben und auch nicht auf dem Status gelöscht stehen und an alle Emails die in escalationLevel1RecipientList stehen. Der Absender ist die emailSenderAddress aus der Kategorie
  
• Wie: bedingungslos
  

3) Template: “RequestForChange.accepted”

• Wo: Request for Change Detail
  
• Wann: Benutzer akzeptiert “Request for Change”
  
• Wer: Der Absender ist die emailSenderAddress aus der Kategorie. Empfänger ist der RFC-Bearbeitende (Verantwortliche)
  
• Wie: bedingungslos
  

4) Template: “8DReport.ChangeResponsible”

• Wo: 8D-Report
  
• Wann: jedesmal bei 8D-Report Änderungen
  
• Wer: Benutzer die für den 8D-Report verantwortlich sind, Absender ist die defaultSenderAddress in der tbGlobalSettings
  
• Wie: bedingungslos
  

5) Template: “forwardscheduleofchanges.task.completed”, “for-wardscheduleofchanges.task.completed.sms”, “forwardsched-uleofchanges.task.failed” or “forwardscheduleof-changes.task.failed.sms”

• Wo: ForwardScheduleOfChange TaskDetail
  
• Wann: jedes Mal, wenn Benutzer Änderungen FSC-Task-Status vornimmt
  
• Wer: Benutzer der nächsten Aufgabe oder processorUser
  
• Wie: nur, wenn die emailNotification oder smsNotification der nächsten Aufgabe auf “true” gesetzt ist, oder im Falle des processorUser - wenn entweder notifyAlways des FSC auf “true” gesetzt ist, oder wenn notifyOnlyOverdue des FSC auf “true” gesetzt ist und die aktuelle Aufgabe überfällig ist
  

6) Template: “forwardscheduleofchanges.alltasksprocessed”

• Wo: ForwardScheduleOfChange TaskDetail
  
• Wann: bei Änderungen durch den Benutzer im FSC Task Status der letzten Aufgabe des FSC
  
• Wer: processorUser
  
• Wie: nur dann, wenn emailNotification oder smsNotification des FSC auf “true” gesetzt ist und es keine Aufgaben links in der Statusleiste gibt, die geplant sind
  

7) Template: “external.supportcase.create”

• Wo: SupportCaseDetail
  
• Wann: Benutzer erstellt neuen Support-Fall
  
• Wer: Kunden, die den Fall erstellt haben
  
• Wie: Nur wenn die emailNotification des Kunden auf „true“ gesetzt ist
  

8) Template: “internal.supportcase.create” or “problem.create”

• Wo: SupportCaseDetail ProblemDetail
  
• Wann: Benutzer erstellt einen neuen Support Fall oder ein Problem, bei Änderungen in der Kategorie eines Falles, bei Änderungen in einem Support Level oder wenn ein Fall wieder geöffnet wird
  
• Wer: Mitglieder des Supportteams, die in der Katgerie des Falles sind in dem der Fall erstellt wurde
  
• Wie: nur wenn der Benutzer nicht gelöscht ist, die emailNotification istauf “true” gesetzt und besitzt das Recht “Case.SendEmail.Internal”
  

9) Template: “supportcase.close”

• Wo: SupportCaseDetail ProblemDetail
  
• Wann: Benutzer ändert den Status eines Falles oder schliesst das Problem
  
• Wer: Benutzer die den Fall erstellt haben
  
• Wie: nur dann, wenn globalSettings.sendCaseCloseMails auf “true” gesetzt ist, wenn der Benutzer der den Fall erstellt hat nicht geschlossen hat, schliesst sich dieser von selbst, emailNotification des Benutzer der den Fall erstellt hat ist auf “true” gesetzt
  

10) Template: “casenote”

• Wo: SupportCaseDetail ProblemDetail
  
• Wann: Bei Problems im Falle des Supportteams, der Eintrag in den GlobalSettings nicht berücksichtigt, ausserdem muss das Recht Case.SendMail.Internal vorhanden sein.
  
• Wer: Empfänger sind Mitglieder des Supportteams und Problem-Owner
  
• Wie: nur dann, wenn der Benutzer nicht gelöscht ist, wenn die emailNotification auf “true” gesetzt ist, und über die richtige “Case.SendEmail.Internal” in einer der Rollen zugewiesen ist
  

11) Template: “problem.externalLastStatus”

• Wo: RemedyWebService
  
• Wann: externalLastStatus des Problems wurde durch RemedyWebService verändert
  
• Wer: ownerUser des Problems
  
• Wie: nur dann, wenn die emailNotification der ownerUser des Problems auf “true” gesetzt ist
  

1) Template: “supportcase.escalate.tolevel.1” und “support-case.escalate.tolevel.2”

• Wo: CaseTrackingService
  
• Wann: der Fall eskaliert im Level 1 oder 2
  
• Wer: escalationLevel1RecipientList und escalationLevel2RecipientList in der Kategorie des Falles in der es eskaliert ist
  
• Wie: nur dann, wenn sendEmailNotification in der Kategorie des Falles eskaliert ist und auf “true” gesetzt ist
  

2) Template: “supportcase.escalate.overdue”

• Wo: CaseTrackingService
  
• Wann: Fall wird als überfällig gekennzeichnet
  
• Wer: alle Benutzer, die in einem Team sind welches der Kategorie zugeordnet ist in dem der Fall als überfällig gekennzeichnet ist
  
• Wie: nur, wenn der Benutzer wird nicht gelöscht ist, die escalationEmails sind auf „true“ gesetzt und ist über die richtige “Case.SendEmail.Internal” in einer der Rollen zugewiesen
  

3) Template: “supportcase.poll”

• Wo: CaseTrackingService
  
• Wann: dateClosed eines Support Falles erstellt mit aktivierter Umfragefunktionalität erreicht glo-balSettings.sendCaseCloseMailDelay
  
• Wer: Kunden die im Fall vorhanden sind
  
• Wie: nur dann, wenn die Kunden-E-Mail zur Verfügung steht und pollEmails des Kunden auf “true” gesetzt ist
  

4) Template: “requestforchange.escalate”

• Wo: CaseTrackingService
  
• Wann: der Antrag auf Änderung seines Status dateCreated “vorgeschlagen” hat globalSet erreicht tings.escalationRfCThreshold
  
• Wer: allen Benutzer, die das Recht “RFC.Manage” besitzen
  
• Wie: bedingungslos