Difference between revisions of "Services Request Configuration"

From Hornbill
Jump to navigation Jump to search
 
(10 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/request-configuration Hornbill Document Library].
 +
 +
[[file:hornbill-document-library.png|Request Configuration|link=https://docs.hornbill.com/servicemanager-user-guide/service-portfolio/request-configuration]]
 +
<!--
 +
 +
 
<div style="border:1px solid #90C0FF; background:#D0E0FF; width:99%; padding:4px; margin-bottom:10px;">
 
<div style="border:1px solid #90C0FF; background:#D0E0FF; width:99%; padding:4px; margin-bottom:10px;">
 
__NOTOC__[[Main Page|Home]] > [[Service Manager]] > [[Service Portfolio]] > [[Service Details]] > Services Request Configuration
 
__NOTOC__[[Main Page|Home]] > [[Service Manager]] > [[Service Portfolio]] > [[Service Details]] > Services Request Configuration
Line 22: Line 28:
 
== [[File:IncidentIcon.png |25px|link=|Incident]] Incident ==
 
== [[File:IncidentIcon.png |25px|link=|Incident]] Incident ==
 
<div style="width:73%">
 
<div style="width:73%">
:* '''Incident Configuration'''
+
===Incident Configuration===
 
<div class="mw-collapsible mw-collapsed" data-collapsetext="Show Less" data-expandtext="Read More">  
 
<div class="mw-collapsible mw-collapsed" data-collapsetext="Show Less" data-expandtext="Read More">  
 
::Setup and configure Incident Management for this Service.
 
::Setup and configure Incident Management for this Service.
Line 58: Line 64:
 
[[File:Service_Categories.png|right|500px|Link=]]
 
[[File:Service_Categories.png|right|500px|Link=]]
 
:: Define which logging and resolution categories are available per request type per service. It is possible to configure which level of the category tree will be the starting level (exposed) when choosing a category on a request, either using Progressive Capture or on the Request Details from. If a Category Level is not selected, the root of the category tree will be used.
 
:: Define which logging and resolution categories are available per request type per service. It is possible to configure which level of the category tree will be the starting level (exposed) when choosing a category on a request, either using Progressive Capture or on the Request Details from. If a Category Level is not selected, the root of the category tree will be used.
 +
::'''Note:''' If the Category Level is filtered to the last level on a branch, no Categories will be visible for selection.
 
<BR>
 
<BR>
 
</div>
 
</div>
Line 111: Line 118:
 
[[File:Service_Categories.png|right|500px|Link=]]
 
[[File:Service_Categories.png|right|500px|Link=]]
 
:: Define which logging and resolution categories are available per request type per service. It is possible to configure which level of the category tree will be the starting level (exposed) when choosing a category on a request, either using Progressive Capture or on the Request Details from. If a Category Level is not selected, the root of the category tree will be used.
 
:: Define which logging and resolution categories are available per request type per service. It is possible to configure which level of the category tree will be the starting level (exposed) when choosing a category on a request, either using Progressive Capture or on the Request Details from. If a Category Level is not selected, the root of the category tree will be used.
 +
::'''Note:''' If the Category Level is filtered to the last level on a branch, no Categories will be visible for selection.
 
<BR>
 
<BR>
 
</div>
 
</div>
Line 134: Line 142:
 
:* '''Enabled / Disabled'''
 
:* '''Enabled / Disabled'''
 
:: Setting this to ''Enabled'' will make this request type available for use when raising requests against this service.  When set to ''Disabled'', this request type will not be available in Progressive Capture or when raising linked requests for this service.
 
:: Setting this to ''Enabled'' will make this request type available for use when raising requests against this service.  When set to ''Disabled'', this request type will not be available in Progressive Capture or when raising linked requests for this service.
 +
 
:* '''Workflow'''
 
:* '''Workflow'''
 
:: The Workflow is an optional setting that allows you to associate a workflow which will be used as the default Workflow for all requests associated to this service. If left blank, the workflows that are specified in the ''app.requests.defaultBPMProcess'' Service Manager Settings will be used. If a Request Catalog Item is used the workflow in the Catalog Item will supersede both these settings.   
 
:: The Workflow is an optional setting that allows you to associate a workflow which will be used as the default Workflow for all requests associated to this service. If left blank, the workflows that are specified in the ''app.requests.defaultBPMProcess'' Service Manager Settings will be used. If a Request Catalog Item is used the workflow in the Catalog Item will supersede both these settings.   
:* '''Catalog Items'''
+
 
::The Catalog Items are used to create a catalog of defined requests which can be used on the Portals or by Support Staff to raise requests to fulfill a specific requirement for that particular Service. Catalog item you can define the following:
 
 
:* '''Email Template'''
 
:* '''Email Template'''
 
:: The Email Template is an optional setting that allows you to associate an email template which will be used when sending emails from within a request using the [[Email Action Item]]. If left blank, the email template specified in the ''app.email.template.request.sendMessage'' Service Manager Setting. If both the Email Template option and the Service Manager Setting are not set, a blank plain text email will be sent without a template.
 
:: The Email Template is an optional setting that allows you to associate an email template which will be used when sending emails from within a request using the [[Email Action Item]]. If left blank, the email template specified in the ''app.email.template.request.sendMessage'' Service Manager Setting. If both the Email Template option and the Service Manager Setting are not set, a blank plain text email will be sent without a template.
Line 157: Line 165:
 
[[File:Service_Categories.png|right|500px|Link=]]
 
[[File:Service_Categories.png|right|500px|Link=]]
 
:: Define which logging and resolution categories are available per request type per service. It is possible to configure which level of the category tree will be the starting level (exposed) when choosing a category on a request, either using Progressive Capture or on the Request Details from. If a Category Level is not selected, the root of the category tree will be used.
 
:: Define which logging and resolution categories are available per request type per service. It is possible to configure which level of the category tree will be the starting level (exposed) when choosing a category on a request, either using Progressive Capture or on the Request Details from. If a Category Level is not selected, the root of the category tree will be used.
 +
::'''Note:''' If the Category Level is filtered to the last level on a branch, no Categories will be visible for selection.
 
<BR>
 
<BR>
 
</div>
 
</div>
 
</div>
 
</div>
 
</div>
 
</div>
 +
 +
:* '''Catalog Items'''
 +
::The Catalog Items are used to create a catalog of defined requests which can be used by Support Staff to raise requests to fulfill a specific requirement for that particular Service.
 +
 
:* '''[[Request Sub-statuses|Sub-Statuses]]'''
 
:* '''[[Request Sub-statuses|Sub-Statuses]]'''
 
:: The Request Sub-statuses lets you define a number of descriptive states of a request that are related to the request being either Active or On-hold. Using a Sub-status can help control the situations under which a request is put On-hold or made Active again. An example of an On-hold Sub-status might be ''With Customer'' which when selected could place the request's status to On-hold and stop any allocated Service Level Target timers.
 
:: The Request Sub-statuses lets you define a number of descriptive states of a request that are related to the request being either Active or On-hold. Using a Sub-status can help control the situations under which a request is put On-hold or made Active again. An example of an On-hold Sub-status might be ''With Customer'' which when selected could place the request's status to On-hold and stop any allocated Service Level Target timers.
Line 196: Line 209:
 
[[File:Service_Categories.png|right|500px|Link=]]
 
[[File:Service_Categories.png|right|500px|Link=]]
 
:: Define which logging and resolution categories are available per request type per service. It is possible to configure which level of the category tree will be the starting level (exposed) when choosing a category on a request, either using Progressive Capture or on the Request Details from. If a Category Level is not selected, the root of the category tree will be used.
 
:: Define which logging and resolution categories are available per request type per service. It is possible to configure which level of the category tree will be the starting level (exposed) when choosing a category on a request, either using Progressive Capture or on the Request Details from. If a Category Level is not selected, the root of the category tree will be used.
 +
::'''Note:''' If the Category Level is filtered to the last level on a branch, no Categories will be visible for selection.
 
<BR>
 
<BR>
 
</div>
 
</div>
 
</div>
 
</div>
 
</div>
 
</div>
 +
 +
:* '''Catalog Items'''
 +
::The Catalog Items are used to create a catalog of defined requests which can be used by Support Staff to raise requests to fulfill a specific requirement for that particular Service.
 +
 
:* '''[[Request Sub-statuses|Sub-Statuses]]'''
 
:* '''[[Request Sub-statuses|Sub-Statuses]]'''
 
:: The Request Sub-statuses lets you define a number of descriptive states of a request that are related to the request being either Active or On-hold. Using a Sub-status can help control the situations under which a request is put On-hold or made Active again. An example of an On-hold Sub-status might be ''With Customer'' which when selected could place the request's status to On-hold and stop any allocated Service Level Target timers.
 
:: The Request Sub-statuses lets you define a number of descriptive states of a request that are related to the request being either Active or On-hold. Using a Sub-status can help control the situations under which a request is put On-hold or made Active again. An example of an On-hold Sub-status might be ''With Customer'' which when selected could place the request's status to On-hold and stop any allocated Service Level Target timers.
Line 242: Line 260:
 
[[File:Service_Categories.png|right|500px|Link=]]
 
[[File:Service_Categories.png|right|500px|Link=]]
 
:: Define which logging and resolution categories are available per request type per service. It is possible to configure which level of the category tree will be the starting level (exposed) when choosing a category on a request, either using Progressive Capture or on the Request Details from. If a Category Level is not selected, the root of the category tree will be used.
 
:: Define which logging and resolution categories are available per request type per service. It is possible to configure which level of the category tree will be the starting level (exposed) when choosing a category on a request, either using Progressive Capture or on the Request Details from. If a Category Level is not selected, the root of the category tree will be used.
 +
::'''Note:''' If the Category Level is filtered to the last level on a branch, no Categories will be visible for selection.
 
<BR>
 
<BR>
 
</div>
 
</div>
Line 247: Line 266:
 
</div>
 
</div>
 
:* '''[[Request Catalog |Catalog Items]]'''
 
:* '''[[Request Catalog |Catalog Items]]'''
:: The Catalog Items are used to create a catalog of defined requests which can be used on the Portals or by Support Staff to raise requests to fulfill a specific requirement for that particular Service. Catalog Items can be added to both Incidents and Service Requests.  For each Catalog item you can define the following:
+
:: The Catalog Items are used to create a catalog of defined requests which can be used on the Portals or by Support Staff to raise requests to fulfill a specific requirement for that particular Service.  
  
 
:* '''[[Request Sub-statuses|Sub-Statuses]]'''
 
:* '''[[Request Sub-statuses|Sub-Statuses]]'''
Line 291: Line 310:
 
[[File:Service_Categories.png|right|500px|Link=]]
 
[[File:Service_Categories.png|right|500px|Link=]]
 
:: Define which logging and resolution categories are available per request type per service. It is possible to configure which level of the category tree will be the starting level (exposed) when choosing a category on a request, either using Progressive Capture or on the Request Details from. If a Category Level is not selected, the root of the category tree will be used.
 
:: Define which logging and resolution categories are available per request type per service. It is possible to configure which level of the category tree will be the starting level (exposed) when choosing a category on a request, either using Progressive Capture or on the Request Details from. If a Category Level is not selected, the root of the category tree will be used.
 +
::'''Note:''' If the Category Level is filtered to the last level on a branch, no Categories will be visible for selection.
 
<BR>
 
<BR>
 
</div>
 
</div>
 
</div>
 
</div>
 
</div>
 
</div>
 +
 +
:* '''Catalog Items'''
 +
::The Catalog Items are used to create a catalog of defined requests which can be used by Support Staff to raise requests to fulfill a specific requirement for that particular Service.
 +
 
:* '''[[Request Sub-statuses|Sub-Statuses]]'''
 
:* '''[[Request Sub-statuses|Sub-Statuses]]'''
 
:: The Request Sub-statuses lets you define a number of descriptive states of a request that are related to the request being either Active or On-hold. Using a Sub-status can help control the situations under which a request is put On-hold or made Active again. An example of an On-hold Sub-status might be ''With Customer'' which when selected could place the request's status to On-hold and stop any allocated Service Level Target timers.
 
:: The Request Sub-statuses lets you define a number of descriptive states of a request that are related to the request being either Active or On-hold. Using a Sub-status can help control the situations under which a request is put On-hold or made Active again. An example of an On-hold Sub-status might be ''With Customer'' which when selected could place the request's status to On-hold and stop any allocated Service Level Target timers.
 
</div>
 
</div>
 +
[[Category:Service Manager]]
 +
-->
 +
[[Category:HDOC]]

Latest revision as of 21:50, 22 April 2024

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

Request Configuration