Difference between revisions of "Request Sub-statuses"

From Hornbill
Jump to navigation Jump to search
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
This document can now be found at its new location in the [https://docs.hornbill.com/servicemanager-user-guide/service-portfolio/services/request-sub-statuses Hornbill Document Library].
 +
 +
[[file:hornbill-document-library.png|Request Sub-statuses|link=https://docs.hornbill.com/servicemanager-user-guide/service-portfolio/services/request-sub-statuses]]
 +
<!--
 +
 +
 
{{bluebanner|[[Main Page|Home]] > [[Service Manager]] > [[Service Portfolio]] > [[Service Details]] > [[Services Request Configuration]] > Request Sub-statuses|[[:Category:Service Manager|Index]]}}
 
{{bluebanner|[[Main Page|Home]] > [[Service Manager]] > [[Service Portfolio]] > [[Service Details]] > [[Services Request Configuration]] > Request Sub-statuses|[[:Category:Service Manager|Index]]}}
 
{{IntroAndLinks|[[file:substatus.png|right|350px|link=https://wiki.hornbill.com/images/6/6a/Substatus.png]]
 
{{IntroAndLinks|[[file:substatus.png|right|350px|link=https://wiki.hornbill.com/images/6/6a/Substatus.png]]
Line 4: Line 10:
 
:* Create descriptive sub-statuses to enhance the New, Open, and Resolved statuses
 
:* Create descriptive sub-statuses to enhance the New, Open, and Resolved statuses
 
:* Have better control over placing requests on hold
 
:* Have better control over placing requests on hold
:* Automate the changing of the sub-statuses|
+
:* Automate the changing of the sub-statuses
 +
:* Define [[Global Request Sub-statuses]] that are applied to all requests for a specific request type |
 
:* [[Services Request Configuration]]
 
:* [[Services Request Configuration]]
 
:* [[Global Request Sub-statuses]]
 
:* [[Global Request Sub-statuses]]
Line 12: Line 19:
  
 
== Sub-status Configuration ==
 
== Sub-status Configuration ==
The creation and management of the Request Sub-statuses is done from within each individual Service form. Each individual sub-status contains the following options.
+
The creation and management of the Request Sub-statuses is done from within each individual Service form. Click on the ''+ New Sub-status'' button to add a new sub-status, or select the edit icon on an existing sub-status.
 +
 
 +
Each individual sub-status contains the following options.
 
:*'''Sub-status Name'''
 
:*'''Sub-status Name'''
 
::The Name of the sub-status is what will be displayed to an analyst from within a request
 
::The Name of the sub-status is what will be displayed to an analyst from within a request
Line 40: Line 49:
  
 
== On Customer Response Change Sub-Status to...==
 
== On Customer Response Change Sub-Status to...==
Sub-statuses can often be used for scenarios where a request has been put on hold as some feedback or an update is required by the customer before proceeding.  The ''On Customer Response'' options allows the sub-status to automatically change to the selected sub-status when the customer performs one of the following actions on the request in the Self Service Portals or when an email update is received on a request
+
Sub-statuses can often be used for scenarios where a request has been put on hold as some feedback or an update is required by the customer before proceeding.  When the ''On Customer Response'' option is set, this allows the sub-status to automatically change to the selected sub-status when one of the following actions is performed on the request:
  
 
'''Self Service Actions'''
 
'''Self Service Actions'''
 
+
<br>The sub-status will change automatically when the Customer...
:* Adds a comment to a post
+
:* adds a comment to a post
:* Adds a post (update)
+
:* adds a post (update)
:* Adds an attachment
+
:* adds an attachment
:* Confirms a resolution has worked
+
:* confirms a resolution has worked
:* Confirms a resolution hasn't worked
+
:* confirms a resolution hasn't worked
  
 
'''Email Actions'''
 
'''Email Actions'''
 +
<br>The sub-status will change automatically when an email is...
 +
:* manually applied to a request
 +
:* automatically added to a request via email Routing Rules
  
:* Manually applied emails to a Request
+
It's not possible to tailor this behaviour beyond the scenarios listed above.
:* Emails Automatically added to a Request via Routing Rules
 
 
 
By Default both Manual and Routing Rule based email updates will constitute a customer update, this can be changed if required through the following system settings:
 
 
 
:* '''app.email.allowRequestSubStatusUpdates''' - Allow automated Sub-status updates on requests when applying an update from email
 
:* '''app.email.routing.rules.allowRequestSubStatusUpdates''' - Allow automated Sub-status updates on requests from auto responder updates
 
  
 
== On Auto Off-hold Change Sub-Status to... ==
 
== On Auto Off-hold Change Sub-Status to... ==
Line 67: Line 73:
 
</blockquote>
 
</blockquote>
  
[[Category:Service Manager]]
+
== Plug-ins==
 +
{{bullet1|[[Supplier Manager]]|With Supplier Manager installed you can automate the starting of Supplier Contract events from Service Manager Requests}}
 +
{{ExpandSection|SMContracts|Contract Requirements|
 +
[[File:smplugin1.png|thumb|link=https://wiki.hornbill.com/images/f/fa/Smplugin1.png]]|
 +
In order to link a Service Manager request to a Supplier Contract, you must have an active Contract with associated assets|
 +
{{bullet1|Activate Contract|Be sure that a Supplier has a contract set up and that the contract status is set to ''Active''.  The current date must also fall within the ''Start'' and ''End'' dates of the contract}}
 +
{{bullet1|Assets|Link assets to both the supplier and the contract. When an asset is associated to a Service Manager request, the supplier and contract for the asset will be available to select.}}
 +
{{bullet1|Events|Optionally, an event can be added to the contract.  Within the ''Event Details'' section of the contract you can add an Event that has a set target time (in minutes). This can be used as the expected response or fix time from the supplier.  The amount of time left in a Supplier Event will be visible on the Service Manager request that is linked to the contract. The ''Contact Email'', also defined in the ''Event Details'' section is displayed on a request to allow an agent to get in touch with the supplier when an issue occurs with one of their assets. The setting '''app.request.stopActiveSupplierContractEventOnResolution'''is provided to allow events to automatically end when a linked request is resolved.}}
 +
}}
 +
{{ExpandSection|Sub-status|Sub-status Configuration|
 +
[[File:smplugin2.png|thumb|link=https://wiki.hornbill.com/images/2/26/Smplugin2.png]]|
 +
The Supplier Manager plug-in is used in conjunction with Service Manager [[Request Sub-statuses]].|
 +
{{bullet1|Enable Supplier|Either on the [[Global_Request_Sub-statuses|global sub-status in Admin]] or on the [[Request Sub-statuses|Service based sub-status]], enable this switch}}
 +
}}
 +
{{ExpandSection|UsingSMPlugin|Using the Plug-in|
 +
[[File:smplugin3.png|thumb|link=https://wiki.hornbill.com/images/5/57/Smplugin3.png]]|
 +
The Supplier Manager plug-in is initiated when a sub-status is selected which has the Supplier Integration enabled.|
 +
{{bullet1|Link Asset|Using the Asset Action on a request, link an asset to the request}}
 +
{{bullet1|Sub-status|Select Sub-status (eg With Supplier) that has the plug-in enabled on it.}}
 +
{{bullet1|Supplier and Contract|You will be prompted to select the Supplier and the contract that is associated to both the supplier and the linked asset.}}
 +
{{bullet1|Supplier Information|Once a request is linked to a supplier and contract, this information will be displayed on the right hand side of the request form.}}
 +
}}
 +
-->
 +
[[Category:HDOC]]

Latest revision as of 21:07, 2 May 2024

This document can now be found at its new location in the Hornbill Document Library.

Request Sub-statuses