Incident Management Implementation Template


You can optimize the deployment of incident management using two different templates. Their main difference lies in the way in which notifications are managed and displayed in the History of Actions, i.e. the timeline intended for the Support team.

Their implementation is modular. It uses both common and specific resources as well as options based on your requirements.

Description of templates

  • Incident template with full history:
    • This is based on the [INCIDENT] Processing | Workflow notifications workflow.
    • It enables you to process an incident from the time it was reported by a user to its resolution by the Support team, followed by approval from the recipient.
    • It is used to send all notifications from the workflow and to store all emails in the History of Actions for full traceability.
  • Incident template with simplified history:
    • This is based on the [INCIDENT] Processing | Email notifications workflow.
    • The processing here is similar to that of the workflow in the previous template.
    • The sending of emails is performed outside the workflow. Emails are not sent directly by the workflow but are sent by business rules to simplify display in the history.
      • Only processing actions and emails sent by wizards (e.g. Send Email to Requestor) will be displayed in the history.
      • Standard notifications will not be displayed, e.g. creation acknowledgment email sent to requestor/recipient, creation notification email sent to the Support team.

Package contents

        EN - Summary table.png

Notes

  • The integration files to be used with the integration templates shipped in the packages can be found in fichiers_csv.rar.
  • Languages L1 to L6 are not supported in the multilingual mechanisms. English is the default language.

Caution

  • You must not modify the external value in the business rules. This is because it is used to identify the [INCIDENT] Processing | Email notifications workflow used by the package with simplified history.

Definitions and concepts

Workflows

[INCIDENT] Immediate solution
  • This is used to manage the resolution of incidents in a ticket.
  • It is run if you find a solution as soon as the ticket is created and click Resolve.
  • It sends a closing notification email to the requestor and to the recipient if they are different individuals.

Open url.png See the configuration.

Workflow - Immediate resolution.png
[INCIDENT] Creation through FrontOffice / TSA
  • This is used to create an incident via the user portal. The status of the incident will be New.
  • It sends a creation notification email to the requestor and to the recipient if they are different individuals.
  • It does not ensure the full processing of the incident. It sends an incident requalification request to the Support team.
  • Once the incident is requalified:
    • The incident will use the [INCIDENT] Processing | Workflow notifications or [INCIDENT] Processing | Email notifications workflow.
    • Its status will change to In Progress.

Open url.png See the configuration.

Workflow - Creation via Front Office and AST.png
[INCIDENT] Processing | Workflow notifications
  • This enables the Support team to process incidents while storing a comprehensive history of all exchanges between users and Support persons.
  • It ensures that different actions for users and Support persons are generated, e.g. creation, analysis, information request, approval, rejection, closing, etc.
  • It also ensures that notification emails are sent to the relevant users and Support persons, e.g. creation acknowledgment email, notification for action, approval email, etc.
Best Practice icon.png You should use this workflow if you are required to justify and audit all exchanges for a given incident.

Open url.png See the configuration.

Workflow - Notifications included.png
[INCIDENT] Processing | Email notifications
  • This enables the Support team to process incidents while storing a simplified history that comprises only actions generated by Support persons.
  • The mechanism is similar to that of the [INCIDENT] Processing | Workflow notifications workflow. The only differences are listed below:
    • Only the Analysis, Approval, Information Request and Rejection steps are kept.
    • The emails associated with these steps are deleted.
  • Notification emails are sent via different business rules instead of the workflow, e.g. creation acknowledgment, notification for action, approval email, closing email, etc.
  • Emails generated by wizards can be sent from the workflow, e.g. Send Email to Requestor.

Open url.png See the configuration.

Workflow - External notifications.png

Business rules

(BR) Creation notification | Outbound email
  • This is used to send an incident creation notification email to the requestor and to the recipient if they are different individuals.
  • It can be used together with the [INCIDENT] Processing | Email notifications workflow.
  • It will not duplicate emails sent by the [INCIDENT] Processing | Workflow notifications workflow.

Open url.png See the configuration.

BR - Creation notification - External email.png
(BR) Processing notification | Outbound email
  • This is used to send an email alerting the Support team that a new incident has been created and must be processed.
  • It can be used together with the [INCIDENT] Processing | Email notifications workflow.
  • It will not duplicate emails sent by the [INCIDENT] Processing | Workflow notifications workflow.

Open url.png See the configuration.

BR - Process notification - External email.png
(BR) Approval Required notification | Outbound email
  • This is used to send an email asking the recipient to check whether the incident has been correctly solved and if so, to notify approval.
  • It can be used together with the [INCIDENT] Processing | Email notifications workflow.
  • It will not duplicate emails sent by the [INCIDENT] Processing | Workflow notifications workflow.

Open url.png See the configuration.

BR - Validation notification - External email.png
(BR) Rejection notification | Outbound email
  • This is used to send an email alerting the Support team that the recipient has rejected the solution of the incident and denied approval.
  • It can be used together with the [INCIDENT] Processing | Email notifications workflow.
  • It will not duplicate emails sent by the [INCIDENT] Processing | Workflow notifications workflow.

Open url.png See the configuration.

BR - Reject notification - External email.png
(BR) More info required notif. | Outbound email
  • This is used to send an email alerting the Support team that the recipient has requested additional information after incident resolution.
  • It can be used together with the [INCIDENT] Processing | Email notifications workflow.
  • It will not duplicate emails sent by the [INCIDENT] Processing | Workflow notifications workflow.

Open url.png See the configuration.

BR - Information request notification - External email.png
(BR) Closing notification | Outbound email
  • This is used to send an email informing the recipient that the incident has been permanently closed.
  • It can be used together with the [INCIDENT] Processing | Email notifications workflow.
  • It will not duplicate emails sent by the [INCIDENT] Processing | Workflow notifications workflow.

Open url.png See the configuration.

BR - Close notification - External email.png
(BR) Notification upon processing incident - Hand icon
  • This is used to send an email alerting the recipient that the incident is being processed by a Support person who self-assigned the action by clicking wiki - Template Incident part 1_html_26bc2c5a.png in the notification bar.
  • This is an optional business rule.
  • It is run only for the first processing action.
  • It will not be run again even if the incident is escalated.

Open url.png See the configuration.

BR - Take charge notification - Hand icon.png
(BR) Escalation notification - Transfer Wizard
  • This is used to send an email to the Support team in charge of the next action when the incident is escalated or redirected.
  • It is run in the following three cases:
    • Redirect to a Group of the same Level
    • Escalate to a Group of a higher Level
    • Redirect to a Group of a lower Level
  • It belongs to the common set of business rules.

Open url.png See the configuration.

BR - Escalate notification - Transfer wizard.png
(BR) Recalculate SLA when rejected
  • This is used to update information in the database after the recipient has rejected the solution of the incident and denied approval.
  • Affected fields: The incident solution date is reinitialized and the SLA target date is recalculated.
  • This belongs to the common set of business rules.

Open url.png See the configuration.

BR - Reject validation - SLA recalculate.png
(BR) Merging all the questions into a form field
  • This is used to merge all answers from a questionnaire into a single field. This takes into account all possible types of questions. This enables you to view all of the answers in a given questionnaire easily without selecting the Questions/Responses tab.
  • Answers are stored in six languages, i.e. FR, EN, SP, GE, IT and PO, in a single field.
  • This is an optional business rule.

Open url.png See the configuration.

BR - Merge questions form field.png
(BR) Automatic closing of incidents via webservice
  • This is used to automatically close incidents when user approval is not performed within a given deadline.
  • It is run using the alert called Automatic closing of incidents after 5 days.
  • It relies on a web service step that uses the Product name - ev itsm.png SOAP or REST EZV_CloseRequest method.
  • You can configure the deadline for the automatic closing of incidents.
  • An email will be sent to users informing them of the automatic closing of their incidents.
  • This belongs to the common set of business rules.

Open url.png See the configuration.

BR - Close request - SOAP.png
(BR) Automatic reopening of on hold incidents
  • This is used to reopen incidents that were suspended.
  • It relies on a web service step that uses the Product name - ev itsm.png SOAP or REST EZV_RestartRequest method.
  • It can be run:
    • Using the Automatic reopening of suspended incidents alert that compares the current date with the incident resumption date.
    • When the suspended incident is updated via a user email sent to the Technical Support Agent (Note: In Other Parameters, the {AST} Support return email address parameter must be enabled).
  • This is an optional business rule.

Open url.png See the configuration.

BR - Restart request - SOAP.png

Alerts

Alert | Automatic closing of incidents after 5 days
  • This automatically triggers the business rule called (BR) Automatic closing of incidents via webservice.

Open url.png See the configuration.

Alert | Automatic reopening of suspended incidents
  • This triggers the business rule called (BR) Automatic reopening of on hold incidents | Due date.

Open url.png See the configuration.

Reporting

Reporting | Automatic closing of incidents after 5 days
  • This is used to check all incidents to be closed after five days when user approval has not been performed.
  • It uses the same filter as the alert called Automatic closing of incidents after 5 days.
  • The alert is usually run every evening. The administrator can check the log to ensure that the alert updates the corresponding records correctly.

Open url.png See the configuration.

Reporting | Automatic reopening of suspended incidents
  • This is used to check all incidents to be reopened after being suspended.
  • It uses the same filter as the alert called Automatic reopening of suspended incidents.
  • The alert is usually run hourly. The administrator can check the log to ensure that the alert updates the corresponding records correctly.

Open url.png See the configuration.

Procedure: How to implement incident management

Step 1: Import the package.

1. Download the required version of the files below to your workstation.

        Download icon.png  Package with full history (notifications via the workflow) 

        Download icon.png  Package with simplified history (notifications via business rules)

2. Extract the RAR files in a folder.

3. Import the ZIP files to Product name - ev itsm.png by selecting Administration > Import/Export > Import in the menu.

  • Full history: (exp)_incident_template_timeline_full_emails_via_wf.zip
  • Simplified history: (exp)_incident_template_timeline_light_emails_via_br.zip

Note: The fichiers_csv folder contains examples of CSV files that you can use to integrate data such as groups, roles, Support persons and incident catalogs. You can use these files together with the integration models in the ZIP file you previously downloaded.

Step 2 (optional): Configure the web services used in SOAP business rules.

Note: Only if you are using the following business rules from the package with simplified history: 

  • (BR) Automatic closing of incidents | SOAP
  • (BR) Automatic reopening of on hold incidents | SOAP

1. Declare the SOAP web services.

  • Select Administration > Parameters > Web services in the menu.
  • Add the EZV_CloseRequest and RestartRequest methods via wiki - Template Incident part 2_html_m19151120.png.

2. Configure the step in the business rule process using the EZV_CloseRequest method.

  • Select Administration > Business Rules > Related Processes in the menu.
  • Edit the process called (BR) Automatic closing of incidents | SOAP.
  • Double-click the step called EZV_CloseRequest.
  • Specify the Account, Login, Password and RFC_NUMBER parameters. Open url.png See the configuration of the business rule.

3. Configure the step in the business rule process using the EZV_RestartRequest method.

  • Edit the process called (BR) Automatic reopening of on hold incidents | SOAP.
  • Double-click the step called EZV_RestartRequest.
  • Specify the Account, Login, Password and RFC_NUMBER parameters. Open url.png See the configuration of the business rule.


Step 3 (optional): Configure the web services used in REST business rules.

Note: Only if you are using the following business rules from the package with simplified history: 

  • (BR) Automatic closing of incidents | REST
  • (BR) Automatic reopening of on hold incidents | REST

1. Declare the REST connection.

Note: The EasyVista service and resource have already been configured. You only need to configure the connection.

  • Select Administration > REST > Connections in the menu.
  • Click Add icon.png to create an EasyVista connection.
  • Specify the Account, Login and Password parameters.

2. Configure the step in the business rule process using the Close incident or request resource.

  • Select Administration > Business Rules > Related Processes in the menu.
  • Edit the process called (BR) Automatic closing of incidents | REST.
  • Double-click the step called REST_CloseRequest.
  • Specify the incident_id and statusGuid_value parameters. Open url.png See the configuration of the business rule.

3. Configure the step in the business rule process using the Restart incident or request resource.

  • Edit the process called (BR) Automatic reopening of on hold incidents | REST.
  • Double-click the step called REST_RestartRequest.
  • Specify the incident_id parameter. Open url.png See the configuration of the business rule.

Step 4: Configure the mail component template for approving the incident solution.

1. Select Administration > Parameters > Mail Components in the menu.

2. Configure the different sections of the mail component.

Configuration of the header

a. Select the _HEADER mail component and run the Update wizard.

b. Select the logo and click Insert/Edit Image wiki - Template Incident part 2_html_m467e9390.png.

c. Modify the Source code field by replacing the variables in yellow with the values corresponding to your context.

  • You are using an On Premise version:

http(s)://<server_name>/Styles/Easyvista/Images/logo_ezv.png

  • You are using an SaaS version:

https://<server_name>/Styles/CLIENT_1/Easyvista/Images/logo_ezv.png

d. Click OK.

Configuration of the footer

a. Copy mailpart_pictures that you imported to the web server in step 1 and paste it in the www/resources/public folder.

b. Select the _FOOTER mail component and run the Update wizard.

b. Select the three icons and click Insert/Edit Image wiki - Template Incident part 2_html_m467e9390.png.

d. Modify the Source code field by replacing the variables in yellow with the values corresponding to your context.

http(s)://localhost/resources/public/mailpart_pictures/picto1.png

http(s)://localhost/resources/public/mailpart_pictures/picto2.png

http(s)://localhost/resources/public/mailpart_pictures/picto3.png

Configuration of the body

a. Select the _BODY_VALIDATION mail component and run the Update wizard.

b. Modify the Accept and Reject links for the incident by replacing the variables in yellow with the email address of the Technical Support Agent in charge of processing incoming emails.

  • Accept link: 

mailto:easyvista@no-reply.com?subject=Approval%20accepted%20(#RFC_NUMBER#)&body=To%20accept%20the%20approval%20of%20your%20incident,%20you%20can%20simply%20click%20the%20button%27to%20send%20this%20email.%0ADo%20not%20modify%20the%20text%20found%20below.%20%0A%0A%0A@OPERATION@%3D%27SOLVE%27%0A@RFC_NUMBER@%3D%27#RFC_NUMBER#%27%0A@CHOICE@%3D%271%27

  • Reject link: 

mailto:easyvista@no-reply.com?subject=Approval%20rejected%20(#RFC_NUMBER#)&body=To%20reject%20the%20approval%20of%20your%20incident,%20you%20can%20simply%20click%20the%20button%27to%20send%20this%20email.%0ADo%20not%20modify%20the%20text%20found%20below.%20%0A%0A%0A@OPERATION@%3D%27SOLVE%27%0A@RFC_NUMBER@%3D%27#RFC_NUMBER#%27%0A@CHOICE@%3D%270%27

 

Note for the Oxygen version only:

          In the approval email, you can also add a link to the customer portal.

1. Select Administration > Parameters > Other Parameters in the menu.

  • Select the parameter called {ADMIN} Enable auto connection link in emails for individual users.
  • Run the Update wizard and set the value to False.

2. Select the _BODY_VALIDATION mail component and run the Update wizard.

  • Delete the Accept and Reject links.
  • Insert the link to the customer portal. The link is in the following format. You should replace the variables in yellow with the values corresponding to your context.

    https://<Apps server name>/index.php?name=com.csm.5a0c7491bb0d1%7C57eccd6de8713&SearchValue=#RFC_NUMBER#

Step 5 (automatic): Configure wizards after importing EXP files.

        Open url.png See the configuration of wizards.

Transfer

  • Only the Group and Support Person fields will appear.
  • The Comment field will be deleted.
     

Approval

  • The sending of an email after user rejection will be deleted.

Detailed configuration

Configuration of workflows

[INCIDENT] Immediate solution

        Workflow - Immediate resolution.png

Step Name: Email ack sent to the end user upon closing
         wiki - Template Incident part 3_html_1213f79b.png

  • Action Type: Send Email
  • Role: @Requestor
  • Cc: @Recipient
  • Return Address: easyvista@no-reply.com
  • Subject: [EasyVista] Your incident is now closed (#RFC_NUMBER#)
  • Message:
         #[E-MAIL_PART._HEADER]#
         #[E-MAIL_PART._BODY_CLOSED]#
         #[E-MAIL_PART._FOOTER]#

[INCIDENT] Creation through FrontOffice / TSA

        Workflow - Creation via Front Office and AST.png

(1) Step Name: Email ack sent to the end user upon creation
         wiki - Template Incident part 3_html_4d4c2957.png

  • Action Type: Send Email
  • Role: @Requestor
  • Cc: @Recipient
  • Return Address: easyvista@no-reply.com
  • Subject: [EasyVista] Your incident has been created (#RFC_NUMBER#)
  • Message:
         #[E-MAIL_PART._HEADER]#
         #[E-MAIL_PART._BODY_CREATION]#
         #[E-MAIL_PART._FOOTER]#
     

(2) Step Name: Requalification

        wiki - Template Incident part 3_html_m33b432b3.png

  • Action Type: Closing Operation 
  • Role: @Catalog Group
  • Action Type: Closing Operation
  • Entry Status: New
  • Return Address: easyvista@no-reply.com
  • Subject: [EasyVista] Action needed on incident for "#RECIPIENT#" (#RFC_NUMBER#)
  • Message:
         #[E-MAIL_PART._HEADER]#
         #[E-MAIL_PART._BODY_PROCESS]#
         #[E-MAIL_PART._FOOTER]#

[INCIDENT] Processing | Workflow notifications

        Workflow - Notifications included.png

(1) Step Name: 1 mail only (even upon requalification)

Objective: Send one email only when the incident is created.

        wiki - Template Incident part 4_html_m65b33a0f.png

  • SQL Condition:
SELECT a.REQUEST_ID
FROM SD_REQUEST a
INNER JOIN AM_ACTION b ON a.REQUEST_ID = b.REQUEST_ID
WHERE ACTION_TYPE_ID = 18 AND DONE_BY_ID IS NULL AND GROUP_ID IS NULL
AND a.REQUEST_ID = @@ID@@;

(2) Step Name: Email ack sent to the end user upon creation
         wiki - Template Incident part 4_html_m45cd661.png

  • Action Type: Send Email
  • Role: @Requestor
  • Cc: @Recipient
  • Return Address: easyvista@no-reply.com
  • Subject: [EasyVista] Your incident has been created (#RFC_NUMBER#)
  • Message:
         #[E-MAIL_PART._HEADER]#
         #[E-MAIL_PART._BODY_CREATION]#
         #[E-MAIL_PART._FOOTER]#
     

(3) Step Name: Support Analysis
         wiki - Template Incident part 4_html_m32f4b26e.png

  • Action Type: Closing Operation 
  • Role: @Catalog Group
  • Entry Status: In Progress
  • Return Address: easyvista@no-reply.com
  • Subject: [EasyVista] New Incident for "#RECIPIENT#" (#RFC_NUMBER#)
  • Message:
         #[E-MAIL_PART._HEADER]#
         #[E-MAIL_PART._BODY_PROCESS]#
         #[E-MAIL_PART._FOOTER]#
     

(4) Step Name: Self Service Approval by the end user

Objective: Offer three choices to the user: Accept, Reject and Information Request.

Caution: Remember to modify the wizard and delete the email to be sent at the end of processing because this will duplicate the email sent in step (7). To do this, you should hide all of the fields in the step. Open url.png See the configuration of wizards.
         wiki - Template Incident part 4_html_76d36814.png

  • Action Type: Self Service Approval (Yes, No, Information Request)
    Note: The Self Service Approval with Survey action type offers only two choices: Accept or Reject. If you use it, you must delete steps (5) and (7).
  • Role: @Recipient
  • Entry Status: Solved
  • Return Address: easyvista@no-reply.com
  • Subject: [EasyVista] Could you please approve your incident (#RFC_NUMBER#)
  • Message:
         #[E-MAIL_PART._HEADER]#
         #[E-MAIL_PART._BODY_VALIDATION]#
         #[E-MAIL_PART._FOOTER]#
     

(5) Step Name: More info (RISK_DESCRIPTION)

Objective: Store the user comment in the information request in order to send it by email to the closing group via the update of SD_REQUEST. RISK_DESCRIPTION.
         wiki - Template Incident part 4_html_m21a3a0f8.png

  • SQL Condition:
UPDATE SD_REQUEST
SET RISK_DESCRIPTION =
(SELECT COALESCE(NULLIF(RTRIM(DESCRIPTION),''),'N/A')
FROM (SELECT MAX(ACTION_ID) MAX_ACTION_ID FROM AM_ACTION
WHERE REQUEST_ID  = @@ID@@ AND ACTION_TYPE_ID IN (1, 31, 38)) A
INNER JOIN AM_ACTION B ON A.MAX_ACTION_ID = B.ACTION_ID)
WHERE REQUEST_ID = @@ID@@;

(6) Step Name: Approval rejected (RISK_DESCRIPTION)

Objective: Store the user comment in the approval rejection in order to send it by email to the closing group via the update of SD_REQUEST. RISK_DESCRIPTION.
         wiki - Template Incident part 4_html_m7cd66b6e.png

  • SQL Condition:
UPDATE SD_REQUEST
SET RISK_DESCRIPTION =
(SELECT COALESCE(NULLIF(RTRIM(DESCRIPTION),''),'N/A')
FROM (SELECT MAX(ACTION_ID) MAX_ACTION_ID FROM AM_ACTION
WHERE REQUEST_ID  = @@ID@@ AND ACTION_TYPE_ID IN (1, 31, 38)) A
INNER JOIN AM_ACTION B ON A.MAX_ACTION_ID = B.ACTION_ID)
WHERE REQUEST_ID = @@ID@@;

(7) Step Name: More info required by the end user
         wiki - Template Incident part 4_html_m739c06e9.png

  • Action Type: Closing Operation 
  • Role: @Closing Group
  • Entry Status: Solved
  • Return Address: easyvista@no-reply.com
  • Subject: [EasyVista] The end user "#RECIPIENT#" has asked for more information (#RFC_NUMBER#)
  • Message:
         #[E-MAIL_PART._HEADER]#
         #[E-MAIL_PART._BODY_MORE_INFOS]#
         #[E-MAIL_PART._FOOTER]#
     

(8) Step Name: Processing end user rejection

Note: At this stage of the workflow, the reinitialization of the initial solution date (SD_REQUEST.END_DATE_UT) and the recalculation of the SLA target date (SD_REQUEST.MAX_RESOLUTION_DATE_UT) will be performed via the business rule called (BR) Recalculate SLA when rejected.
         wiki - Template Incident part 4_html_m3a995ce3.png

  • Action Type: Closing Operation 
  • Role: @Closing Group
  • Entry Status: Reopened
  • Return Address: easyvista@no-reply.com
  • Subject: [EasyVista] Incident solution rejected by "#RECIPIENT#" (#RFC_NUMBER#)
  • Message:
         #[E-MAIL_PART._HEADER]#
         #[E-MAIL_PART._BODY_DENIED]#
         #[E-MAIL_PART._FOOTER]#
     

(9) Step Name: Email ack sent to the end user upon closing
         wiki - Template Incident part 4_html_3d1d727.png

  • Action Type: Send Email
  • Role: @Requestor
  • Cc: @Recipient
  • Return Address: easyvista@no-reply.com
  • Subject: [EasyVista] Your incident is now closed (#RFC_NUMBER#)
  • Message:
         #[E-MAIL_PART._HEADER]#
         #[E-MAIL_PART._BODY_CLOSED]#
         #[E-MAIL_PART._FOOTER]#

[INCIDENT] Processing | Email notifications

        Workflow - External notifications.png

The mechanism is similar to that of the [INCIDENT] Processing | Workflow notifications workflow. The only differences are listed below:

  • Steps kept in the workflow:
    • Step (3): Support Analysis
    • Step (4): Self Service Approval
    • Step (7): More info required by the end user
    • Step (8): Processing end user rejection

Within these steps, emails are sent via business rules. You must delete all of the names and messages in these steps to avoid sending duplicates.

  • Steps deleted from the workflow:
    • Step (1): 1 mail only (even upon requalification)
    • Step (2): Email ack sent to the end user upon creation
    • Step (5): More info (RISK_DESCRIPTION)
    • Step (6): Approval rejected (RISK_DESCRIPTION)
    • Step (9): Email ack sent to the end user upon closing

Configuration of business rules (workflows)

(BR) Creation notification | Outbound email

        BR - Creation notification - External email.png

(1) Step Name: Email ack sent to the end user upon creation
         wiki - Template Incident part 5_html_m79c320f5.png

  • Action Type: Send Email
  • Role: @Requestor
  • Cc: @Recipient
  • Return Address: easyvista@no-reply.com
  • Subject: [EasyVista] Your incident has been created (#RFC_NUMBER#)
  • Message:
         #[E-MAIL_PART._HEADER]#
         #[E-MAIL_PART._BODY_CREATION]#
         #[E-MAIL_PART._FOOTER]#
     

(2) Objective of the step: Store a trace of the incident number.

  • SQL Condition:
SELECT TOP 1 RFC_NUMBER FROM AM_ACTION
INNER JOIN SD_REQUEST ON AM_ACTION.REQUEST_ID = SD_REQUEST.REQUEST_ID
WHERE ACTION_ID = @@ID@@;

(3) Objective of the step: Store the initial description of the incident.

  • SQL Condition:
SELECT TOP 1 SD_REQUEST.COMMENT FROM AM_ACTION
INNER JOIN SD_REQUEST ON AM_ACTION.REQUEST_ID = SD_REQUEST.REQUEST_ID
WHERE ACTION_ID = @@ID@@;

(BR) Processing notification | Outbound email

        BR - Process notification - External email.png

(1) Step Name: Support Analysis

Caution: Remember to modify the Transfer wizard (redirection or escalation) in the Action form and delete the email to be sent at the end of processing. To do this, you should hide all of the fields in the step. Open url.png See the configuration of the Transfer wizard.
         wiki - Template Incident part 5_html_m2daeccb7.png

  • Action Type: Send Email
  • Role: #[CUSTOM_ROLE.Groups with an Action to complete]#
  • Cc: #[CUSTOM_ROLE.List of Support Persons with an Action to be executed]#
  • Return Address: easyvista@no-reply.com
  • Subject: [EasyVista] New Incident for "#RECIPIENT#" (#RFC_NUMBER#)
  • Message:
         #[E-MAIL_PART._HEADER]#
         #[E-MAIL_PART._BODY_PROCESS]#
         #[E-MAIL_PART._FOOTER]#
     

(2) Objective of the step: Store a trace of the incident number.

  • SQL Condition:
SELECT TOP 1 RFC_NUMBER FROM AM_ACTION
INNER JOIN SD_REQUEST ON AM_ACTION.REQUEST_ID = SD_REQUEST.REQUEST_ID
WHERE ACTION_ID = @@ID@@;

(3) Objective of the step: Store the initial description of the incident.

  • SQL Condition:
SELECT TOP 1 SD_REQUEST.COMMENT FROM AM_ACTION
INNER JOIN SD_REQUEST ON AM_ACTION.REQUEST_ID = SD_REQUEST.REQUEST_ID
WHERE ACTION_ID = @@ID@@;

(BR) Approval Required notification | Outbound email

        BR - Validation notification - External email.png

(1) Step Name: Self Service Approval by the end user
         wiki - Template Incident part 5_html_479caa84.png

  • Action Type: Send Email
  • Role: @Recipient
  • Return Address: easyvista@no-reply.com
  • Subject: [EasyVista] Could you please approve your incident (#RFC_NUMBER#)
  • Message:
         #[E-MAIL_PART._HEADER]#
         #[E-MAIL_PART._BODY_VALIDATION]#
         #[E-MAIL_PART._FOOTER]#
     

(2) Objective of the step: Store a trace of the incident number.

  • SQL Condition:
SELECT TOP 1 RFC_NUMBER FROM AM_ACTION
INNER JOIN SD_REQUEST ON AM_ACTION.REQUEST_ID = SD_REQUEST.REQUEST_ID
WHERE ACTION_ID = @@ID@@;

(3) Objective of the step: Store the initial description of the incident.

  • SQL Condition:
SELECT TOP 1 SD_REQUEST.COMMENT FROM AM_ACTION
INNER JOIN SD_REQUEST ON AM_ACTION.REQUEST_ID = SD_REQUEST.REQUEST_ID
WHERE ACTION_ID = @@ID@@;

(BR) Rejection notification | Outbound email

        BR - Reject notification - External email.png

(1) Step Name: Processing end user rejection
         wiki - Template Incident part 5_html_m63492fb6.png

  • Action Type: Send Email
  • Role: @Closing Group
  • Return Address: easyvista@no-reply.com
  • Subject: [EasyVista] Incident solution rejected by "#RECIPIENT#" (#RFC_NUMBER#)
  • Message:
         #[E-MAIL_PART._HEADER]#
         #[E-MAIL_PART._BODY_DENIED]#
         #[E-MAIL_PART._FOOTER]#
     

(2) Objective of the step: Retrieve the user rejection comment to update SD_REQUEST.RISK_DESCRIPTION and send it to the closing group.

  • SQL Condition:
UPDATE SD_REQUEST
SET RISK_DESCRIPTION =
(SELECT COALESCE(NULLIF(RTRIM(DESCRIPTION),''),'N/A')
FROM (SELECT MAX(ACTION_ID) MAX_ACTION_ID FROM AM_ACTION
WHERE REQUEST_ID = (SELECT REQUEST_ID FROM AM_ACTION WHERE ACTION_ID = @@ID@@)
AND ACTION_TYPE_ID IN (1, 31, 38)) A INNER JOIN AM_ACTION B ON A.MAX_ACTION_ID = B.ACTION_ID)
FROM SD_REQUEST
INNER JOIN AM_ACTION ON SD_REQUEST.REQUEST_ID = AM_ACTION.REQUEST_ID
WHERE ACTION_ID = @@ID@@;

(3) Objective of the step: Store a trace of the incident number.

  • SQL Condition:
SELECT TOP 1 RFC_NUMBER FROM AM_ACTION
INNER JOIN SD_REQUEST ON AM_ACTION.REQUEST_ID = SD_REQUEST.REQUEST_ID
WHERE ACTION_ID = @@ID@@;

(4) Objective of the step: Store the initial description of the incident.

  • SQL Condition:
SELECT TOP 1 SD_REQUEST.COMMENT FROM AM_ACTION
INNER JOIN SD_REQUEST ON AM_ACTION.REQUEST_ID = SD_REQUEST.REQUEST_ID
WHERE ACTION_ID = @@ID@@;

(BR) More info required notif. | Outbound email

        BR - Information request notification - External email.png

(1) Step Name: More info required by the end user
         wiki - Template Incident part 5_html_6d22f0d2.png

  • Action Type: Send Email
  • Role: @Closing Group
  • Return Address: easyvista@no-reply.com
  • Subject: [EasyVista] The end user "#RECIPIENT#" has asked for more information (#RFC_NUMBER#)
  • Message:
         #[E-MAIL_PART._HEADER]#
         #[E-MAIL_PART._BODY_MORE_INFOS]#
         #[E-MAIL_PART._FOOTER]#
     

(2) Objective of the step: Retrieve the information request comment to update SD_REQUEST.RISK_DESCRIPTION and send it to the closing group.

  • SQL Condition:
UPDATE SD_REQUEST
SET RISK_DESCRIPTION =
(SELECT COALESCE(NULLIF(RTRIM(DESCRIPTION),''),'N/A')
FROM (SELECT MAX(ACTION_ID) MAX_ACTION_ID FROM AM_ACTION
WHERE REQUEST_ID = (SELECT REQUEST_ID FROM AM_ACTION WHERE ACTION_ID = @@ID@@)
AND ACTION_TYPE_ID IN (1, 31, 38)) A INNER JOIN AM_ACTION B ON A.MAX_ACTION_ID = B.ACTION_ID)
FROM SD_REQUEST
INNER JOIN AM_ACTION ON SD_REQUEST.REQUEST_ID = AM_ACTION.REQUEST_ID
WHERE ACTION_ID = @@ID@@;

(3) Objective of the step: Store a trace of the incident number.

  • SQL Condition:
SELECT TOP 1 RFC_NUMBER FROM AM_ACTION
INNER JOIN SD_REQUEST ON AM_ACTION.REQUEST_ID = SD_REQUEST.REQUEST_ID
WHERE ACTION_ID = @@ID@@;

(4) Objective of the step: Store the initial description of the incident.

  • SQL Condition:
SELECT TOP 1 SD_REQUEST.COMMENT FROM AM_ACTION
INNER JOIN SD_REQUEST ON AM_ACTION.REQUEST_ID = SD_REQUEST.REQUEST_ID
WHERE ACTION_ID = @@ID@@;

(BR) Closing notification | Outbound email

        BR - Close notification - External email.png

(1) Step Name: Email ack sent to the end user upon closing
wiki - Template Incident part 6_html_m16e5d933.png

  • Action Type: Send Email
  • Role: @Requestor
  • Cc: @Recipient
  • Return Address: easyvista@no-reply.com
  • Subject: [EasyVista] Your incident is now closed (#RFC_NUMBER#)
  • Message:
         #[E-MAIL_PART._HEADER]#
         #[E-MAIL_PART._BODY_CLOSED]#
         #[E-MAIL_PART._FOOTER]#
     

(2) Objective of the step: Store a trace of the incident number.

  • SQL Condition:
SELECT TOP 1 RFC_NUMBER FROM AM_ACTION
INNER JOIN SD_REQUEST ON AM_ACTION.REQUEST_ID = SD_REQUEST.REQUEST_ID
WHERE ACTION_ID = @@ID@@;

(3) Objective of the step: Store the initial description of the incident.

  • SQL Condition:
SELECT TOP 1 SD_REQUEST.COMMENT FROM AM_ACTION
INNER JOIN SD_REQUEST ON AM_ACTION.REQUEST_ID = SD_REQUEST.REQUEST_ID
WHERE ACTION_ID = @@ID@@;

(BR) Notification upon processing incident - Hand icon

        BR - Take charge notification - Hand icon.png

(1) Step Name: Email ack sent to the end user upon handling the incident
wiki - Template Incident part 6_html_m4933ffb5.png

  • Action Type: Send Email
  • Role: @Requestor
  • Cc: @Recipient
  • Return Address: easyvista@no-reply.com
  • Subject: [EasyVista] Your incident is now being handled by the Support Team (#RFC_NUMBER#)
  • Message:
         #[E-MAIL_PART._HEADER]#
         #[E-MAIL_PART._BODY_IN_PROGRESS]#
         #[E-MAIL_PART._FOOTER]#
     

(2) Objective of the step: Store a trace of the incident number.

  • SQL Condition:
SELECT TOP 1 RFC_NUMBER FROM AM_ACTION
INNER JOIN SD_REQUEST ON AM_ACTION.REQUEST_ID = SD_REQUEST.REQUEST_ID
WHERE ACTION_ID = @@ID@@;.

(3) Objective of the step: Store the initial description of the incident.

  • SQL Condition:
SELECT TOP 1 SD_REQUEST.COMMENT FROM AM_ACTION
INNER JOIN SD_REQUEST ON AM_ACTION.REQUEST_ID = SD_REQUEST.REQUEST_ID
WHERE ACTION_ID = @@ID@@;

(BR) Escalation notification - Transfer Wizard

        BR - Escalate notification - Transfer wizard.png

(1) Step Name: Store a trace of the incident number.

  • SQL Condition:
SELECT TOP 1 RFC_NUMBER FROM AM_ACTION
INNER JOIN SD_REQUEST ON AM_ACTION.REQUEST_ID = SD_REQUEST.REQUEST_ID
WHERE ACTION_ID = @@ID@@;

(2) Objective of the step: Retrieve the escalation comment to update SD_REQUEST.RISK_DESCRIPTION and use it in a mail component (_BODY_ESCALATED).

  • SQL Condition:
UPDATE SD_REQUEST
SET RISK_DESCRIPTION =
(SELECT COALESCE(NULLIF(RTRIM(REPLACE(DESCRIPTION,'''','´')),''),'N/A')
FROM AM_ACTION WHERE ACTION_ID
IN (SELECT MAX(ACTION_ID) AS MAX_ACTION_ID
FROM AM_ACTION WHERE ACTION_TYPE_ID in (20, 34)
AND DONE_BY_ID IS NOT NULL AND START_DATE_UT IS NOT NULL AND
END_DATE_UT IS NOT NULL AND
REQUEST_ID = (SELECT REQUEST_ID FROM AM_ACTION WHERE ACTION_ID = @@ID@@) GROUP BY REQUEST_ID))
FROM SD_REQUEST
INNER JOIN AM_ACTION ON SD_REQUEST.REQUEST_ID = AM_ACTION.REQUEST_ID
WHERE ACTION_ID = @@ID@@;

(3) Objective of the step: Update the next action with the comment from the previous action (escalation, same-level or lower-level redirection).

  • SQL Condition:
UPDATE AM_ACTION SET DESCRIPTION = '#[DB_FIELDS.REQUEST_ID.SD_REQUEST.RISK_DESCRIPTION]#'
WHERE ACTION_TYPE_ID in (20, 34)
AND START_DATE_UT IS NULL AND END_DATE_UT IS NULL AND REQUEST_ID = (SELECT REQUEST_ID FROM AM_ACTION WHERE ACTION_ID = @@ID@@);

(4) Step Name: Email ack when incident is escalated
         wiki - Template Incident part 6_html_5638c103.png

  • Action Type: Send Email
  • Role: #[CUSTOM_ROLE.Groups with an Action to complete]#
  • Cc: #[CUSTOM_ROLE.List of Support Persons with an Action to be executed]#
  • Return Address: easyvista@no-reply.com
  • Subject: [EasyVista] Incident for "#RECIPIENT#" has been transferred/escalated (#RFC_NUMBER#)
  • Message:
         #[E-MAIL_PART._HEADER]#
         #[E-MAIL_PART._BODY_ESCALATED]#
         #[E-MAIL_PART._FOOTER]#

(BR) Recalculate SLA when rejected

        BR - Reject validation - SLA recalculate.png

The SLA target date (SD_REQUEST.MAX_RESOLUTION_DATE_UT) will be recalculated:

  • The start date will be equal to the end date of the user action, i.e. the date on which the user rejected the solution.
  • The smoAddTime function is used.
  • The new SLA target date = End date of the user action + duration defined in the SLA applied to the incident catalog.
     

(2) Objective of the step: Reinitialize the end date of the incident (SD_REQUEST.END_DATE_UT)
wiki - Template Incident part 6_html_2abf8f7f.png

  • SQL Condition:
UPDATE SD_REQUEST SET END_DATE_UT = null
FROM SD_REQUEST
INNER JOIN AM_ACTION ON SD_REQUEST.REQUEST_ID = AM_ACTION.REQUEST_ID
WHERE ACTION_ID = @@ID@@;

(3) Objective of the step: Retrieve the SLA of the incident.
         wiki - Template Incident part 6_html_m59548888.png

  • SQL Condition:
SELECT SD_SLA.DELAY AS DURATION FROM AM_ACTION
INNER JOIN SD_REQUEST ON AM_ACTION.REQUEST_ID = SD_REQUEST.REQUEST_ID
INNER JOIN SD_SLA ON SD_REQUEST.SLA_ID = SD_SLA.SLA_ID
WHERE ACTION_ID = @@ID@@;

(4) Objective of the step: Retrieve the SLA service hours.
         wiki - Template Incident part 6_html_6d19a8d5.png

  • SQL Condition:
SELECT WORKING_HOURS_ID FROM AM_ACTION
INNER JOIN SD_REQUEST ON AM_ACTION.REQUEST_ID = SD_REQUEST.REQUEST_ID
INNER JOIN SD_SLA ON SD_REQUEST.SLA_ID = SD_SLA.SLA_ID
WHERE ACTION_ID = @@ID@@;

(5) Objective of the step: Recalculate the new SLA target date.
         wiki - Template Incident part 6_html_53f2ffd.png

  • SQL Condition:
SELECT {@SD_REQUEST.MAX_RESOLUTION_DATE_UT = smoAddTime(AM_ACTION.END_DATE_UT, #[VAR.WORKING_HOURS_ID]#, #[VAR.DURATION]#, SD_REQUEST.LOCATION_ID, SD_REQUEST.SLA_ID)@}
FROM SD_REQUEST
INNER JOIN AM_ACTION ON SD_REQUEST.REQUEST_ID = AM_ACTION.REQUEST_ID
WHERE ACTION_ID = @@ID@@;

(BR) Merging all the questions into a form field

        BR - Merge questions form field.png

How the business rule works:

  • In a mail component, retrieve the Merging header in the language of the group or Support person in charge of the action. Store the information in a variable called SQL_MERGE_HEADER.
  • In the mail component, retrieve the SQL code for managing the labels of questions and answers in the six languages, i.e. columns TAG_LABEL_FR, TAG_LABEL_EN, TAG_LABEL_SP, TAG_LABEL_GE, TAG_LABEL_IT, TAG_LABEL_PO. Store the information in a variable called SQL_MERGE_QUESTIONS.
  • Update the SD_REQUEST.DYNAMIC_DETAILS field using variables SQL_MERGE_HEADER and SQL_MERGE_QUESTIONS.
     

(1) Objective of the step: Retrieve the Merging header in the language of the Support person via the _SQL_MERGE_HEADER mail component.
         wiki - Template Incident part 6_html_4590f241.png

  • SQL Condition:
SELECT REPLACE(REPLACE(REPLACE(
CASE
WHEN AM_ACTION.DONE_BY_ID is null AND AM_GROUP.LANGUAGE_ID = 1 THEN (SELECT TAG_LABEL_EN FROM SD_E-MAIL_TAG WHERE TAG = '_SQL_MERGE_HEADER')
WHEN AM_ACTION.DONE_BY_ID is null AND AM_GROUP.LANGUAGE_ID = 2 THEN (SELECT TAG_LABEL_FR FROM SD_E-MAIL_TAG WHERE TAG = '_SQL_MERGE_HEADER')
WHEN AM_ACTION.DONE_BY_ID is null AND AM_GROUP.LANGUAGE_ID = 3 THEN (SELECT TAG_LABEL_SP FROM SD_E-MAIL_TAG WHERE TAG = '_SQL_MERGE_HEADER')
WHEN AM_ACTION.DONE_BY_ID is null AND AM_GROUP.LANGUAGE_ID = 4 THEN (SELECT TAG_LABEL_GE FROM SD_E-MAIL_TAG WHERE TAG = '_SQL_MERGE_HEADER')
WHEN AM_ACTION.DONE_BY_ID is null AND AM_GROUP.LANGUAGE_ID = 5 THEN (SELECT TAG_LABEL_IT FROM SD_E-MAIL_TAG WHERE TAG = '_SQL_MERGE_HEADER')
WHEN AM_ACTION.DONE_BY_ID is null AND AM_GROUP.LANGUAGE_ID = 6 THEN (SELECT TAG_LABEL_PO FROM SD_E-MAIL_TAG WHERE TAG = '_SQL_MERGE_HEADER')
WHEN AM_ACTION.DONE_BY_ID is not null AND AM_EMPLOYEE.LANGUAGE_ID = 1 THEN (SELECT TAG_LABEL_EN FROM SD_E-MAIL_TAG WHERE TAG = '_SQL_MERGE_HEADER')
WHEN AM_ACTION.DONE_BY_ID is not null AND AM_EMPLOYEE.LANGUAGE_ID = 2 THEN (SELECT TAG_LABEL_FR FROM SD_E-MAIL_TAG WHERE TAG = '_SQL_MERGE_HEADER')
WHEN AM_ACTION.DONE_BY_ID is not null AND AM_EMPLOYEE.LANGUAGE_ID = 3 THEN (SELECT TAG_LABEL_SP FROM SD_E-MAIL_TAG WHERE TAG = '_SQL_MERGE_HEADER')
WHEN AM_ACTION.DONE_BY_ID is not null AND AM_EMPLOYEE.LANGUAGE_ID = 4 THEN (SELECT TAG_LABEL_GE FROM SD_E-MAIL_TAG WHERE TAG = '_SQL_MERGE_HEADER')
WHEN AM_ACTION.DONE_BY_ID is not null AND AM_EMPLOYEE.LANGUAGE_ID = 5 THEN (SELECT TAG_LABEL_IT FROM SD_E-MAIL_TAG WHERE TAG = '_SQL_MERGE_HEADER')
WHEN AM_ACTION.DONE_BY_ID is not null AND AM_EMPLOYEE.LANGUAGE_ID = 6 THEN (SELECT TAG_LABEL_PO FROM SD_E-MAIL_TAG WHERE TAG = '_SQL_MERGE_HEADER')
ELSE (SELECT TAG_LABEL_EN FROM SD_E-MAIL_TAG WHERE TAG = '_SQL_MERGE_HEADER')
END

, '<p>', ''), '</p>', ''), '''', '´') AS SQL_MERGE
FROM AM_ACTION
INNER JOIN SD_REQUEST ON AM_ACTION.REQUEST_ID = SD_REQUEST.REQUEST_ID
INNER JOIN AM_GROUP ON AM_ACTION.GROUP_ID = AM_GROUP.GROUP_ID
LEFT OUTER JOIN AM_EMPLOYEE ON AM_ACTION.DONE_BY_ID = AM_EMPLOYEE.EMPLOYEE_ID
WHERE AM_ACTION.END_DATE_UT is null AND AM_ACTION.ACTION_ID = @@ID@@;

(2) Objective of the step: Retrieve the questions and answers from the questionnaire in the language of the Support person via the _SQL_MERGE_QUESTIONS mail component.

        wiki - Template Incident part 6_html_m3f6c581d.png

  • SQL Condition:
SELECT REPLACE(REPLACE(
CASE
WHEN AM_ACTION.DONE_BY_ID is null AND AM_GROUP.LANGUAGE_ID = 1 THEN (SELECT TAG_LABEL_EN FROM SD_E-MAIL_TAG WHERE TAG = '_SQL_MERGE_QUESTIONS')
WHEN AM_ACTION.DONE_BY_ID is null AND AM_GROUP.LANGUAGE_ID = 2 THEN (SELECT TAG_LABEL_FR FROM SD_E-MAIL_TAG WHERE TAG = '_SQL_MERGE_QUESTIONS')
WHEN AM_ACTION.DONE_BY_ID is null AND AM_GROUP.LANGUAGE_ID = 3 THEN (SELECT TAG_LABEL_SP FROM SD_E-MAIL_TAG WHERE TAG = '_SQL_MERGE_QUESTIONS')
WHEN AM_ACTION.DONE_BY_ID is null AND AM_GROUP.LANGUAGE_ID = 4 THEN (SELECT TAG_LABEL_GE FROM SD_E-MAIL_TAG WHERE TAG = '_SQL_MERGE_QUESTIONS')
WHEN AM_ACTION.DONE_BY_ID is null AND AM_GROUP.LANGUAGE_ID = 5 THEN (SELECT TAG_LABEL_IT FROM SD_E-MAIL_TAG WHERE TAG = '_SQL_MERGE_QUESTIONS')
WHEN AM_ACTION.DONE_BY_ID is null AND AM_GROUP.LANGUAGE_ID = 6 THEN (SELECT TAG_LABEL_PO FROM SD_E-MAIL_TAG WHERE TAG = '_SQL_MERGE_QUESTIONS')
WHEN AM_ACTION.DONE_BY_ID is not null AND AM_EMPLOYEE.LANGUAGE_ID = 1 THEN (SELECT TAG_LABEL_EN FROM SD_E-MAIL_TAG WHERE TAG = '_SQL_MERGE_QUESTIONS')
WHEN AM_ACTION.DONE_BY_ID is not null AND AM_EMPLOYEE.LANGUAGE_ID = 2 THEN (SELECT TAG_LABEL_FR FROM SD_E-MAIL_TAG WHERE TAG = '_SQL_MERGE_QUESTIONS')
WHEN AM_ACTION.DONE_BY_ID is not null AND AM_EMPLOYEE.LANGUAGE_ID = 3 THEN (SELECT TAG_LABEL_SP FROM SD_E-MAIL_TAG WHERE TAG = '_SQL_MERGE_QUESTIONS')
WHEN AM_ACTION.DONE_BY_ID is not null AND AM_EMPLOYEE.LANGUAGE_ID = 4 THEN (SELECT TAG_LABEL_GE FROM SD_E-MAIL_TAG WHERE TAG = '_SQL_MERGE_QUESTIONS')
WHEN AM_ACTION.DONE_BY_ID is not null AND AM_EMPLOYEE.LANGUAGE_ID = 5 THEN (SELECT TAG_LABEL_IT FROM SD_E-MAIL_TAG WHERE TAG = '_SQL_MERGE_QUESTIONS')
WHEN AM_ACTION.DONE_BY_ID is not null AND AM_EMPLOYEE.LANGUAGE_ID = 6 THEN (SELECT TAG_LABEL_PO FROM SD_E-MAIL_TAG WHERE TAG = '_SQL_MERGE_QUESTIONS')

ELSE (SELECT TAG_LABEL_EN FROM SD_E-MAIL_TAG WHERE TAG = '_SQL_MERGE_QUESTIONS')
END

, '<p>', ''), '</p>', '') AS SQL_MERGE
FROM AM_ACTION
INNER JOIN SD_REQUEST ON AM_ACTION.REQUEST_ID = SD_REQUEST.REQUEST_ID
INNER JOIN AM_GROUP ON AM_ACTION.GROUP_ID = AM_GROUP.GROUP_ID
LEFT OUTER JOIN AM_EMPLOYEE ON AM_ACTION.DONE_BY_ID = AM_EMPLOYEE.EMPLOYEE_ID
WHERE AM_ACTION.END_DATE_UT is null AND AM_ACTION.ACTION_ID = @@ID@@;

(3) Objective of the step: Merge the questions in the SD_REQUEST.DYNAMIC_DETAILS field while taking into account the different languages (header and body of answers).
         wiki - Template Incident part 6_html_8858177.png

  • SQL Condition:
DECLARE @CPTE1 INT, @CPTE2 INT, @TEXT NVARCHAR(4000)
SELECT
@CPTE1 = MAX(RESULT_ORDER),
@CPTE2 = MIN(RESULT_ORDER) FROM V_SD_QUESTION_RESULT A INNER JOIN AM_ACTION B ON A.REQUEST_ID = B.REQUEST_ID WHERE ACTION_ID = @@ID@@
SET @TEXT=''
WHILE @CPTE2 <= @CPTE1
BEGIN
SET @TEXT=@TEXT+ISNULL((
SELECT
REPLACE(REPLACE(
CASE
**#[VAR.SQL_MERGE_QUESTIONS]#**
END

, '[', ''), ']', '')
FROM V_SD_QUESTION_RESULT A
INNER JOIN AM_ACTION B ON A.REQUEST_ID = B.REQUEST_ID
INNER JOIN SD_QUESTION C ON A.QUESTION_ID = C.QUESTION_ID
WHERE ACTION_ID = @@ID@@
AND VALUE_TYPE <> 'tbl_header' AND VALUE_TYPE <> 'comment'
AND RESULT_ORDER = @CPTE2),'')
SET @CPTE2 = @CPTE2+1
END

UPDATE SD_REQUEST
SET DYNAMIC_DETAILS = '**#[VAR.SQL_MERGE_HEADER]#**'+'<br>'+@TEXT
FROM SD_REQUEST
INNER JOIN AM_ACTION ON SD_REQUEST.REQUEST_ID = AM_ACTION.REQUEST_ID
WHERE ACTION_ID = @@ID@@;

(BR) Automatic closing of incidents | SOAP

        BR - Close request - SOAP.png

(2) Step Name: EZV_CloseRequest
         wiki - Template Incident part 7_html_4c2a76e9.png

Configuration of the web service
         wiki - Template Incident part 7_html_6f2d107b.png

  • Select Administration > Parameters > Web Services in the menu and declare the EZV_CloseRequest method.
  • URL: https://<EasyVista server_name>/WebService/SmoBridge.php?wsdl
     

(3) Objective of the step: Retrieve the text string, /** Incident closed automatically **/ via a mail component. The string will be added to the header of the solution to notify that the incident was closed using a web service.
         wiki - Template Incident part 7_html_5a60e5ef.png

  • SQL Condition:
SELECT CASE
WHEN LANGUAGE_ID = 1 THEN (SELECT TAG_LABEL_EN FROM SD_E-MAIL_TAG WHERE TAG = '_WS_CLOSE_HEADER')
WHEN LANGUAGE_ID = 2 THEN (SELECT TAG_LABEL_FR FROM SD_E-MAIL_TAG WHERE TAG = '_WS_CLOSE_HEADER')
WHEN LANGUAGE_ID = 3 THEN (SELECT TAG_LABEL_SP FROM SD_E-MAIL_TAG WHERE TAG = '_WS_CLOSE_HEADER')
WHEN LANGUAGE_ID = 4 THEN (SELECT TAG_LABEL_GE FROM SD_E-MAIL_TAG WHERE TAG = '_WS_CLOSE_HEADER')
WHEN LANGUAGE_ID = 5 THEN (SELECT TAG_LABEL_IT FROM SD_E-MAIL_TAG WHERE TAG = '_WS_CLOSE_HEADER')
WHEN LANGUAGE_ID = 6 THEN (SELECT TAG_LABEL_PO FROM SD_E-MAIL_TAG WHERE TAG = '_WS_CLOSE_HEADER')
ELSE (SELECT TAG_LABEL_EN FROM SD_E-MAIL_TAG WHERE TAG = '_WS_CLOSE_HEADER')
END AS MESSAGE
FROM SD_REQUEST
INNER JOIN AM_EMPLOYEE ON SD_REQUEST.RECIPIENT_ID = AM_EMPLOYEE.EMPLOYEE_ID
WHERE REQUEST_ID = @@ID@@;

(4) Objective of the step: Update the Solution field with the value of the mail component retrieved in the previous step in the language of the recipient.
         wiki - Template Incident part 7_html_m6c27a45a.png

  • SQL Condition:
UPDATE SD_REQUEST
SET SD_REQUEST.DESCRIPTION = '#[VAR.WS_CLOSE_HEADER]#'
+'<br /><br />'
+ISNULL(DESCRIPTION,'')
FROM SD_REQUEST WHERE SD_REQUEST.REQUEST_ID = @@ID@@;

(BR) Automatic closing of incidents | REST

The configuration is similar to that for SOAP, except that the REST step type is used.
         BR - Close request - REST.png

Select Administration > REST > Connections in the menu to configure the connection.

  • Specify the host name, account, login and password.
  • incident_id parameter: #[DB_FIELDS.RFC_NUMBER]#
  • statusGUID_value parameter: C3D9DFA7-7A21-46C2-B3A3-8BC50C9FF4F3

(BR) Automatic reopening of on hold incidents | SOAP

        BR - Restart request - SOAP.png

The objective of this business rule is to reopen suspended incidents. Two possible scenarios:

  • (BR) Automatic reopening of on hold incidents | Due date
    • Incidents whose resumption date is exceeded will automatically be reopened.
    • The AM_ACTION.EXPECTED_END_DATE_UT field is compared with the current date via an alert and the EZV_RestartRequest web service.
    • The value of Available Field 6 (AM_ACTION.AVAILABLE_FIELD_6) will be 1.
  • (BR) Automatic reopening of on hold incidents | Incoming email
    • The suspended incident is updated via a user email sent to the Technical Support Agent.
    • The incident will be reopened via the alert.
    • The (BR) Automatic reopening of on hold incidents business rule will be run.

(2) Objective of the step: Retrieve the text string, /** Incident reopened automatically **/ via a mail component. It will be added to the AM_ACTION.COMMENT field to notify that the incident was reopened using a web service.
         wiki - Template Incident part 7_html_m352a972e.png

  • SQL Condition:
SELECT REPLACE(REPLACE(
CASE
WHEN AM_ACTION.DONE_BY_ID is null AND AM_GROUP.LANGUAGE_ID = 1 THEN (SELECT TAG_LABEL_EN FROM SD_E-MAIL_TAG WHERE TAG = '_WS_REOPEN_HEADER')
WHEN AM_ACTION.DONE_BY_ID is null AND AM_GROUP.LANGUAGE_ID = 2 THEN (SELECT TAG_LABEL_FR FROM SD_E-MAIL_TAG WHERE TAG = '_WS_REOPEN_HEADER')
WHEN AM_ACTION.DONE_BY_ID is null AND AM_GROUP.LANGUAGE_ID = 3 THEN (SELECT TAG_LABEL_SP FROM SD_E-MAIL_TAG WHERE TAG = '_WS_REOPEN_HEADER')
WHEN AM_ACTION.DONE_BY_ID is null AND AM_GROUP.LANGUAGE_ID = 4 THEN (SELECT TAG_LABEL_GE FROM SD_E-MAIL_TAG WHERE TAG = '_WS_REOPEN_HEADER')
WHEN AM_ACTION.DONE_BY_ID is null AND AM_GROUP.LANGUAGE_ID = 5 THEN (SELECT TAG_LABEL_IT FROM SD_E-MAIL_TAG WHERE TAG = '_WS_REOPEN_HEADER')
WHEN AM_ACTION.DONE_BY_ID is null AND AM_GROUP.LANGUAGE_ID = 6 THEN (SELECT TAG_LABEL_PO FROM SD_E-MAIL_TAG WHERE TAG = '_WS_REOPEN_HEADER')
WHEN AM_ACTION.DONE_BY_ID is not null AND AM_EMPLOYEE.LANGUAGE_ID = 1 THEN (SELECT TAG_LABEL_EN FROM SD_E-MAIL_TAG WHERE TAG = '_WS_REOPEN_HEADER')
WHEN AM_ACTION.DONE_BY_ID is not null AND AM_EMPLOYEE.LANGUAGE_ID = 2 THEN (SELECT TAG_LABEL_FR FROM SD_E-MAIL_TAG WHERE TAG = '_WS_REOPEN_HEADER')
WHEN AM_ACTION.DONE_BY_ID is not null AND AM_EMPLOYEE.LANGUAGE_ID = 3 THEN (SELECT TAG_LABEL_SP FROM SD_E-MAIL_TAG WHERE TAG = '_WS_REOPEN_HEADER')
WHEN AM_ACTION.DONE_BY_ID is not null AND AM_EMPLOYEE.LANGUAGE_ID = 4 THEN (SELECT TAG_LABEL_GE FROM SD_E-MAIL_TAG WHERE TAG = '_WS_REOPEN_HEADER')
WHEN AM_ACTION.DONE_BY_ID is not null AND AM_EMPLOYEE.LANGUAGE_ID = 5 THEN (SELECT TAG_LABEL_IT FROM SD_E-MAIL_TAG WHERE TAG = '_WS_REOPEN_HEADER')
WHEN AM_ACTION.DONE_BY_ID is not null AND AM_EMPLOYEE.LANGUAGE_ID = 6 THEN (SELECT TAG_LABEL_PO FROM SD_E-MAIL_TAG WHERE TAG = '_WS_REOPEN_HEADER')
ELSE (SELECT TAG_LABEL_EN FROM SD_E-MAIL_TAG WHERE TAG = '_WS_REOPEN_HEADER')
END,

'<p>', ''), '</p>', '') AS WS_REOPEN_HEADER
FROM AM_ACTION
INNER JOIN SD_REQUEST ON AM_ACTION.REQUEST_ID = SD_REQUEST.REQUEST_ID
INNER JOIN AM_GROUP ON AM_ACTION.GROUP_ID = AM_GROUP.GROUP_ID
LEFT OUTER JOIN AM_EMPLOYEE ON AM_ACTION.DONE_BY_ID = AM_EMPLOYEE.EMPLOYEE_ID
WHERE ACTION_ID in (SELECT MAX(ACTION_ID) FROM AM_ACTION
WHERE ACTION_TYPE_ID = 5 AND REQUEST_ID = (SELECT REQUEST_ID FROM AM_ACTION WHERE ACTION_ID = @@ID@@) GROUP BY AM_ACTION.REQUEST_ID);

(3) Objective of the step:
         wiki - Template Incident part 7_html_253bd959.png

Configuration of the web service
         wiki - Template Incident part 7_html_6ffc5325.png

  • Select Administration > Parameters > Web services in the menu and declare the EZV_RestartRequest method.
  • URL: https://<EasyVista server_name>/WebService/SmoBridge.php?wsdl
     

(4) Objective of the step: Update the AM_ACTION.COMMENT field of the last resumption action with the following comment: /** Incident reopened automatically **/. The language of the group or Support person in charge of the processing action will be taken into account.
         wiki - Template Incident part 7_html_26a5f678.png

  • SQL Condition:
UPDATE AM_ACTION
SET COMMENT = '**#[VAR.WS_REOPEN_HEADER]#**'
WHERE ACTION_ID IN
(SELECT MAX(ACTION_ID) FROM AM_ACTION
WHERE ACTION_TYPE_ID = 6
AND REQUEST_ID = (SELECT REQUEST_ID FROM AM_ACTION WHERE ACTION_ID = @@ID@@)
GROUP BY REQUEST_ID);

(5) Step Name: Email ack upon reopening the incident
wiki - Template Incident part 7_html_767a99c4.png

  • Action Type: Send Email
  • Role: #[CUSTOM_ROLE.Groups with an Action to complete]#
  • Cc: #[CUSTOM_ROLE.List of Support Persons with an Action to be executed]#
  • Return Address: easyvista@no-reply.com
  • Subject: [EasyVista] Automatic reopening of a suspended incident (#RFC_NUMBER#)
  • Message:
         #[E-MAIL_PART._HEADER]#
         #[E-MAIL_PART._BODY_REOPEN]#
         #[E-MAIL_PART._FOOTER]#

(BR) Automatic reopening of on hold incidents | REST

The configuration is similar to that for SOAP, except that the REST step type is used.
         BR - Restart request - REST.png

Select Administration > REST > Connections in the menu to configure the connection.

  • Specify the host name, account, login and password.
  • incident_id parameter: #[DB_FIELDS.REQUEST_ID.SD_REQUEST.RFC_NUMBER]#

Configuration of business rules (definitions)

(BR) Creation notification | Outbound email

This business rule is run for action types (Call Reception) and 25 (Self Service Request).

  • This is applicable only to workflows containing the external value (for business rule emails).
  • Trigger:  AM_ACTION.END_DATE_UT | On Update
  • SQL Condition:
IF EXISTS (SELECT ACTION_ID FROM INSERTED
INNER JOIN SD_REQUEST ON INSERTED.REQUEST_ID = SD_REQUEST.REQUEST_ID
INNER JOIN SD_CATALOG ON SD_REQUEST.SD_CATALOG_ID = SD_CATALOG.SD_CATALOG_ID
INNER JOIN SD_WORKFLOW ON SD_CATALOG.WORKFLOW_ID = SD_WORKFLOW.WORKFLOW_ID
WHERE INSERTED.ACTION_TYPE_ID in (7, 25) AND INSERTED.END_DATE_UT is not null AND SD_WORKFLOW.NAME_FR like '%external%')
BEGIN
@@FIRETRIGGER@@
END

(BR) Processing notification | Outbound email

This business rule is run for action types 20 (Operation Processing) and 34 (Closing Operation).

  • This is applicable only to workflows containing the external value (for business rule emails).
  • Trigger:  AM_ACTION | On Insert
  • SQL Condition:
IF EXISTS (SELECT ACTION_ID FROM INSERTED
INNER JOIN SD_REQUEST ON INSERTED.REQUEST_ID = SD_REQUEST.REQUEST_ID
INNER JOIN SD_CATALOG ON SD_REQUEST.SD_CATALOG_ID = SD_CATALOG.SD_CATALOG_ID
INNER JOIN SD_WORKFLOW ON SD_CATALOG.WORKFLOW_ID = SD_WORKFLOW.WORKFLOW_ID
WHERE ACTION_TYPE_ID in (20,34) AND WORKFLOW_VALUE is null AND ACTION_NUMBER = 0 AND SD_WORKFLOW.NAME_FR like '%external%')
BEGIN
@@FIRETRIGGER@@
END

(BR) Approval Required notification | Outbound email

This business rule is run for action types 1 (Self Service Approval), 31 (Rating) and 38 (Self Service Approval with Survey).

  • This is applicable only to workflows containing the external value (for business rule emails).
  • Trigger:  AM_ACTION | On Insert
  • SQL Condition:
IF EXISTS (SELECT ACTION_ID FROM INSERTED
INNER JOIN SD_REQUEST ON INSERTED.REQUEST_ID = SD_REQUEST.REQUEST_ID
INNER JOIN SD_CATALOG ON SD_REQUEST.SD_CATALOG_ID = SD_CATALOG.SD_CATALOG_ID
INNER JOIN SD_WORKFLOW ON SD_CATALOG.WORKFLOW_ID = SD_WORKFLOW.WORKFLOW_ID
WHERE INSERTED.ACTION_TYPE_ID in (1, 31, 38)
AND SD_WORKFLOW.NAME_FR like '%external%')
BEGIN
@@FIRETRIGGER@@
END

(BR) Rejection notification | Outbound email

This business rule is run for action types 20 (Operation Processing) and 34 (Closing Operation).

  • This is applicable only to workflows containing the external value (for business rule emails).
  • Trigger:  AM_ACTION | On Insert
  • SQL Condition:
IF EXISTS (SELECT ACTION_ID FROM INSERTED
INNER JOIN SD_REQUEST ON INSERTED.REQUEST_ID = SD_REQUEST.REQUEST_ID
INNER JOIN SD_CATALOG ON SD_REQUEST.SD_CATALOG_ID = SD_CATALOG.SD_CATALOG_ID
INNER JOIN SD_WORKFLOW ON SD_CATALOG.WORKFLOW_ID = SD_WORKFLOW.WORKFLOW_ID
WHERE INSERTED.ACTION_TYPE_ID in (20,34) AND WORKFLOW_VALUE = 0
AND SD_WORKFLOW.NAME_FR like '%external%')
BEGIN
@@FIRETRIGGER@@
END

(BR) More info required notif. | Outbound email

This business rule is run for action types 20 (Operation Processing) and 34 (Closing Operation).

  • This is applicable only to workflows containing the external value (for business rule emails).
  • Trigger:  AM_ACTION | On Insert
  • SQL Condition:
IF EXISTS (SELECT ACTION_ID FROM INSERTED
INNER JOIN SD_REQUEST ON INSERTED.REQUEST_ID = SD_REQUEST.REQUEST_ID
INNER JOIN SD_CATALOG ON SD_REQUEST.SD_CATALOG_ID = SD_CATALOG.SD_CATALOG_ID
INNER JOIN SD_WORKFLOW ON SD_CATALOG.WORKFLOW_ID = SD_WORKFLOW.WORKFLOW_ID
WHERE INSERTED.ACTION_TYPE_ID in (20,34) AND WORKFLOW_VALUE = 2
AND SD_WORKFLOW.NAME_FR like '%external%')
BEGIN
@@FIRETRIGGER@@
END

(BR) Closing notification | Outbound email

This business rule is run for action types 1 (Self Service Approval), 31 (Rating) and 38 (Self Service Approval with Survey).

  • This is applicable only to workflows containing the external value (for business rule emails).
  • Trigger:  AM_ACTION | On Insert
  • SQL Condition:
IF EXISTS (SELECT ACTION_ID FROM INSERTED
INNER JOIN SD_REQUEST ON INSERTED.REQUEST_ID = SD_REQUEST.REQUEST_ID
INNER JOIN SD_CATALOG ON SD_REQUEST.SD_CATALOG_ID = SD_CATALOG.SD_CATALOG_ID
INNER JOIN SD_WORKFLOW ON SD_CATALOG.WORKFLOW_ID = SD_WORKFLOW.WORKFLOW_ID
WHERE INSERTED.ACTION_TYPE_ID in (1, 31, 38) AND INSERTED.END_DATE_UT is not null AND EXIT_VALUE = 1 AND SD_WORKFLOW.NAME_FR like '%external%')
BEGIN
@@FIRETRIGGER@@
END

(BR) Notification upon processing incident - Hand icon

This business rule is run for action types 20 (Operation Processing) and 34 (Closing Operation).

  • Trigger:  AM_ACTION.DONE_BY_ID | On Update
  • SQL Condition:
IF EXISTS (SELECT ACTION_ID FROM INSERTED WHERE START_DATE_UT IS NOT NULL AND ACTION_ID = (SELECT MIN(AM_ACTION.ACTION_ID) FROM AM_ACTION
WHERE AM_ACTION.ACTION_TYPE_ID in (20, 34) AND REQUEST_ID = INSERTED.REQUEST_ID))
BEGIN
@@FIRETRIGGER@@
END

(BR) Escalation notification - Transfer Wizard

This business rule is run for action types 13 (Escalation), 14 (Redirection) and 52 (Redirected to a Level Below).

  • Trigger:  AM_ACTION | On Insert
  • SQL Condition:
IF EXISTS (SELECT ACTION_ID FROM INSERTED
WHERE ACTION_TYPE_ID in (13, 14, 52))
BEGIN
@@FIRETRIGGER@@
END

(BR) Recalculate SLA when rejected

  • The SLA will be recalculated using the following algorithm:
Date de fin de l'action de validation (si refus de validation) + Durée prévue au SLA = Nouvelle date de résolution maximum
  • Trigger:  AM_ACTION.EXIT_VALUE | On Update
  • SQL Condition:
IF EXISTS (SELECT ACTION_ID FROM INSERTED
WHERE ACTION_TYPE_ID in (1, 31, 38) AND EXIT_VALUE = 0)
BEGIN
@@FIRETRIGGER@@
END

(BR) Merging all the questions into a form field

  • The merging of questions takes into account the language of the group or Support person in charge of the action.

    Example documentation icon EN.png English technicians will see the questions in their language. Once the incident is transferred, French technicians will see the questions in their language.

  • Trigger:  AM_ACTION | On Insert
  • SQL Condition:
IF EXISTS (SELECT ACTION_ID FROM INSERTED
INNER JOIN V_SD_QUESTION_RESULT ON INSERTED.REQUEST_ID = V_SD_QUESTION_RESULT.REQUEST_ID
WHERE INSERTED.END_DATE_UT is null AND ACTION_TYPE_ID in (20, 34))
BEGIN
@@FIRETRIGGER@@
END

(BR) Automatic closing of incidents via webservice

This business rule will be run when the Automatic closing of incidents after 5 days
alert is run.

  • The value of the SD_REQUEST.WAVE_ID_TARGET field will be updated to 1 (currently unused field).
  • Trigger:  SD_REQUEST.WAVE_ID_TARGET | On Update
  • SQL Condition:
IF EXISTS (SELECT REQUEST_ID FROM INSERTED
WHERE WAVE_ID_TARGET = '1')
BEGIN
@@FIRETRIGGER@@
END

(BR) Automatic reopening of on hold incidents

This business rule is run:

  • By the Automatic reopening of suspended incidents alert that compares the current date with the incident resumption date to check whether the AM_ACTION.EXPECTED_END_DATE_UT field is exceeded.

    • The value of the AM_ACTION.AVAILABLE_FIELD_6 field will be updated to 1.
    • Trigger:  AM_ACTION.AVAILABLE_FIELD_6 | On Update
    • SQL Condition:
IF EXISTS (SELECT ACTION_ID FROM INSERTED
WHERE ACTION_TYPE_ID = 5
AND EXPECTED_END_DATE_UT is not null
AND AVAILABLE_FIELD_6 = '1')
BEGIN
@@FIRETRIGGER@@
END
  • When a suspended incident is updated via a user email sent to the Technical Support Agent (Note: In Other Parameters, the {AST} Support return email address parameter must be enabled).

    • Trigger:  AM_ACTION | On Insert
    • SQL Condition:
IF EXISTS (SELECT ACTION_ID FROM INSERTED
INNER JOIN SD_REQUEST ON INSERTED.REQUEST_ID = SD_REQUEST.REQUEST_ID
WHERE ACTION_TYPE_ID = 76
AND SD_REQUEST.STATUS_ID = 5)
BEGIN
@@FIRETRIGGER@@
END

Configuration of alerts

Alert | Automatic closing of incidents after 5 days

Parent Query: Action Operation

Alert Type: Standard

Frequency: Every day at 00:00 (UT) i.e. 2 am (CET)

SQL Condition (for filtering):

DATEDIFF(d,SD_REQUEST.END_DATE_UT,getutcdate()) >= 5) AND (AM_ACTION.END_DATE_UT IS NULL) AND (AM_ACTION.ACTION_TYPE_ID IN (1,31,38)) AND (SD_REQUEST_STATUS.STATUS_GUID IN ('{DC97DD1D-0F35-4153-B0E1-0F2E0155365D}')) AND ({# TREEWHERE('SD_CATALOG', 'CATALOG_GUID', '{932E417B-2798-4E45-9918-7FB6A9CB49D5}', 'SD_CATALOG') #})

SQL Condition (for running the business rule):

UPDATE SD_REQUEST
SET WAVE_ID_TARGET = '1'
FROM SD_REQUEST
INNER JOIN AM_ACTION ON AM_ACTION.REQUEST_ID = SD_REQUEST.REQUEST_ID
WHERE (WAVE_ID_TARGET <> '1' or WAVE_ID_TARGET is null)
AND ACTION_ID in (#LIST_ID#);

Alert | Automatic reopening of suspended incidents

Parent Query: Action Operation

Alert Type: Standard

Frequency: Hourly

SQL Condition (for filtering):

AM_ACTION.ACTION_ID IN (SELECT MAX(ACTION_ID) FROM AM_ACTION WHERE ACTION_TYPE_ID = 5 AND EXPECTED_END_DATE_UT is not null AND EXPECTED_END_DATE_UT < GETUTCDATE() GROUP BY REQUEST_ID)

SQL Condition (for running the business rule):

UPDATE AM_ACTION
SET AVAILABLE_FIELD_6 = '1'
WHERE (AVAILABLE_FIELD_6 <> '1' or AVAILABLE_FIELD_6 is null)
AND ACTION_ID in (#LIST_ID#);

Configuration of reporting

Reporting | Automatic closing of incidents after 5 days

Used to check incidents to be closed after five days.

        Reporting - Automatic close.png

Reporting | Automatic reopening of suspended incidents

Used to check incidents to be resumed.

        Reporting - Automatic restart.png

Preview of email templates

        Mail composant template.png

All emails sent by workflows are based on the HEADER / BODY / FOOTER structure using mail components.

  • Header: Modify the path of the logo based on your context.
    • By default, this is the Product name - ev itsm.png logo displayed at the top left.
  • Footer: Customize the Support contact information based on your context, e.g. icons, email address, phone number or customer portal URL.

Configuration of wizards

Transfer wizard in the Action form (HD - Transfer Incident)

The objective of the modifications is to display only the Group and Support Person fields in the Transfer wizard.

The Copy comment from current action to next action and Notifications options are managed by the (BR) Escalation notification - Transfer Wizard business rule.

        Transfer wizard - Configuration 1.png

        Transfer wizard - Configuration 2.png

Approval wizard (WF - Validation)

The objective of the modifications is to hide the user email sent in the rejection notification step. The Support team will be notified by the [INCIDENT] Processing | Workflow notifications workflow or by the (BR) Rejection notification | Outbound email business rule.

        Validation wizard - Configuration.png

Tags:
Last modified by Unknown User on 2018/12/04 09:59
Created by Administrator XWiki on 2018/12/04 09:48

Shortcuts

Recent Updates

Haven't been here in a while? Here's what changed recently:

-   Product name - ev itsm.png
-   Product name - ev sas.png

Interesting Content

How to Automate Integration
Add a Shortcut to an App
History
Quick Dashboard
Full text search - Stop Words

Powered by XWiki ©, EasyVista 2018