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) Nehmen wir an, Sie haben das Template Ihres Interesses gefunden, welches durch das Template „casenote“ erzeugt wurde. Verwenden Sie die
Suchfunktion von “MsWord” um die Stelle zu finden, in der das Template „casenote“ beschrieben wird. Sie werden folgendes finden:

• Wo: SupportCase Detail, ProblemDetail
  
• Wann: Benutzer fügt Anmerkung hinzu
  
• Wer: User des Supportteams, die sich in der Kategorie des Problems befinden
  
• Wie: nur dann wenn „globalSettings.sendCaseNoteMails“ auf „true“ gesetzt ist, Benutzer nicht gelöscht ist, die emailNotification ist auf „true“ gesetzt und besitzt das Recht “Case.SendEmail.Internal”, das in einer der Rollen zugewiesen ist
  

3) Das letzte was zu tun ist, ist, das gefundene Template zu interpretieren.
Die Punkte in der Templatebeschreibung bedeuten folgendes:

• Wo: beschreibt die Stelle der Anwendung, an der sie aufgerufen wird (zum Beispiel, sind sie die Unterstützung bei Problem-und Detail-Formularen)
• Wann: beschreibt, unter welchen Umständen die Vorlage wie heißt (zum Beispiel, wenn der User immer einen Kommentar einfügt)
• Wer: beschreibt wer eine entsprechende Benachrichtigung erhalten hat (zum Beispiel, sind das alle Support-Team Mitglieder, die in der Kategorie des Falles sind
• Wie: beschreibt zusätzliche Bedingungen oder Einschränkungen für ein Template (zum Beispiel, einer der Bedingungen ist, dass „sendCaseNoteMails“ auf „wahr“ gesetzt ist oder der User nicht gelöscht ist)

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