Difference between revisions of "Services Request Configuration"

From Hornbill
Jump to navigation Jump to search
(118 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
<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]] > [[Services]] > Request Configuration
+
__NOTOC__[[Main Page|Home]] > [[Service Manager]] > [[Service Portfolio]] > [[Service Details]] > Services Request Configuration
 
</div>
 
</div>
 
{|style="width: 100%"
 
{|style="width: 100%"
Line 6: Line 6:
 
|style="width:73%"|
 
|style="width:73%"|
 
== Introduction ==
 
== Introduction ==
−
The Service Request Configuration lets you define a number of elements for the different request types that are used for each Service.
+
The Service Request Configuration lets you define a number of elements for the different request types that are used for each Service. This allows each Service to provide its own experience for both the Support Staff and the subscribed customers. 
  
 
|style="width:5%"|
 
|style="width:5%"|
Line 13: Line 13:
  
 
== Related Articles ==
 
== Related Articles ==
 +
:* [[Request_Details_Form_Designer|Request Details Form Designer]]
 +
:* [[Request_Catalog|Request Catalog]]
 +
:* [[Customer_Feedback|Customer Feedback]]
 +
:* [[Request Settings]]
 +
:* [[Request_Sub-statuses|Request Sub-Statuses]]
 
|}
 
|}
  
−
== Configuration ==
+
== [[File:IncidentIcon.png |25px|link=|Incident]] Incident ==
 +
<div style="width:73%">
 +
===Incident Configuration===
 +
<div class="mw-collapsible mw-collapsed" data-collapsetext="Show Less" data-expandtext="Read More">
 +
::Setup and configure Incident Management for this Service.
 +
<div class="mw-collapsible-content">
 +
<div style="border:1px solid #e6e6e6; background:#f2f2f2; width:99%; padding:4px; margin-bottom:10px;">
 +
:* '''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.
 +
:* '''Workflow'''
 +
:: The Workflow is an optional setting that allows you to associate a workflow which will be used as the default Workflow for all Incidents 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. 
 +
 
 +
:* '''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.
 +
 
 +
:* '''Form Designer'''
 +
:: It is possible for you to define custom fields to use against each request type per service.  Using the form designer you can edit which default fields will be displayed in the '''Details''' section of each request form, as well as add new fields, set field  validation, configure mandatory options and using drag and drop to re-order how the required fields will be displayed.
 +
 
 +
:* '''Portal Process Tracker'''
 +
[[File:HUD_Portal.png|right|500px|link=]]
 +
:: When a Business Process Workflow is being used to support either the Service Requests or Incidents, it is possible to define what level of visibility you wish to give to your customers of the Process Tracker.
 +
:::* '''Off''' - The Process Tracker is hidden from customers.
 +
:::* '''Stages Only''' - Only the top level of the Process Tracker that shows the stages will be displayed.
 +
:::* '''Stages and Checkpoints''' -  This will show both the Stages and the checkpoints.
 +
 
 +
:* '''Request Actions'''
 +
[[File:Request_Actions.png|right|500px|Link=]]
 +
:: Define which Actions are available to users on the Request Action bar when working on requests raised against the Service. 
 +
 
 +
:: An example being you may choose not to enable the 'Escalation' Action against Service Requests if you are not using Priorities for requests of this type for a particular Service.  However you have this available for Incidents and Problems where you have chosen to use priorities for those request types.
  
 +
:::* Enable or Disable an Action by clicking on the Action Icon for each Request type
 +
:::* Hover over each Action Icon to see a tooltip with the Action's purpose.
 +
:::* Globally manage which Action items are enabled when a request is on-hold through '''[[Request Settings]]'''
 +
 +
:* '''Request Categories'''
 +
[[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.
 +
::'''Note:''' If the Category Level is filtered to the last level on a branch, no Categories will be visible for selection.
 +
<BR>
 +
</div>
 +
</div>
 +
</div>
 +
 +
:* '''[[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.
 +
 +
:* '''[[Customer Feedback]]'''
 +
::The Customer Feedback options provides a feature to gather feedback from your customers regarding the level of service they have received for a particular request.  This feedback will enable you to identify where excellent service is already being provided, but also highlight any areas where the service to your customers could be improved.
 +
 +
:* '''[[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.
 +
</div>
 +
 +
== [[File:Requesticon.png |25px|link=|Request]] Request ==
 +
<div style="width:73%">
 +
:* '''Request Configuration'''
 +
<div class="mw-collapsible mw-collapsed" data-collapsetext="Show Less" data-expandtext="Read More">
 +
:: Setup and configure Request Management for this Service.
 +
<div class="mw-collapsible-content">
 +
<div style="border:1px solid #e6e6e6; background:#f2f2f2; width:99%; padding:4px; margin-bottom:10px;">
 +
:* '''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.
 
:* '''Workflow'''
 
:* '''Workflow'''
−
:: The Workflow is an optional setting that allows you to associate an existing workflow which will be used as the default Workflow for all requests associated to this service. If left blank, the workflows that are set in the Service Manager Settings '''app.requests.defaultBPMProcess''' 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.   
  
 +
:* '''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.
 +
 +
:* '''Form Designer'''
 +
:: It is possible for you to define custom fields to use against each request type per service.  Using the form designer you can edit which default fields will be displayed in the '''Details''' section of each request form, as well as add new fields, set field  validation, configure mandatory options and using drag and drop to re-order how the required fields will be displayed.
 +
 +
:* '''Portal Process Tracker'''
 +
[[File:HUD_Portal.png|right|500px|link=]]
 +
:: When a Business Process Workflow is being used to support either the Service Requests or Incidents, it is possible to define what level of visibility you wish to give to your customers of the Process Tracker.
 +
:::* '''Off''' - The Process Tracker is hidden from customers.
 +
:::* '''Stages Only''' - Only the top level of the Process Tracker that shows the stages will be displayed.
 +
:::* '''Stages and Checkpoints''' -  This will show both the Stages and the checkpoints.
 +
 +
:* '''Request Actions'''
 +
[[File:Request_Actions.png|right|500px|Link=]]
 +
:: Define which Actions are available to users on the Request Action bar when working on requests raised against the Service. 
 +
 +
:: An example being you may choose not to enable the 'Escalation' Action against Service Requests if you are not using Priorities for requests of this type for a particular Service.  However you have this available for Incidents and Problems where you have chosen to use priorities for those request types.
 +
 +
:::* Enable or Disable an Action by clicking on the Action Icon for each Request type
 +
:::* Hover over each Action Icon to see a tooltip with the Action's purpose.
 +
:::* Globally manage which Action items are enabled when a request is on-hold through '''[[Request Settings]]'''
 +
 +
:* '''Request Categories'''
 +
[[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.
 +
::'''Note:''' If the Category Level is filtered to the last level on a branch, no Categories will be visible for selection.
 +
<BR>
 +
</div>
 +
</div>
 +
</div>
 +
:* '''[[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.
 +
 +
:* '''[[Customer Feedback]]'''
 +
:: The Customer Feedback options provides a feature to gather feedback from your customers regarding the level of service they have received for a particular request.  This feedback will enable you to identify where excellent service is already being provided, but also highlight any areas where the service to your customers could be improved.
 +
 +
:* '''[[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.
 +
</div>
 +
 +
== [[File:Problemicon.png |25px|link=|Problem]] Problem ==
 +
<div style="width:73%">
 +
:* '''Problem Configuration'''
 +
<div class="mw-collapsible mw-collapsed" data-collapsetext="Show Less" data-expandtext="Read More">
 +
::Setup and configure Problem Management for this Service.
 +
<div class="mw-collapsible-content">
 +
<div style="border:1px solid #e6e6e6; background:#f2f2f2; width:99%; padding:4px; margin-bottom:10px;">
 +
:* '''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.
 +
 +
:* '''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. 
  
 
:* '''Email Template'''
 
:* '''Email Template'''
−
:: The Email Template is an optional setting that allows you to associate an existing 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.
−
 
 
  
 
:* '''Form Designer'''
 
:* '''Form Designer'''
 
:: It is possible for you to define custom fields to use against each request type per service.  Using the form designer you can edit which default fields will be displayed in the '''Details''' section of each request form, as well as add new fields, set field  validation, configure mandatory options and using drag and drop to re-order how the required fields will be displayed.  
 
:: It is possible for you to define custom fields to use against each request type per service.  Using the form designer you can edit which default fields will be displayed in the '''Details''' section of each request form, as well as add new fields, set field  validation, configure mandatory options and using drag and drop to re-order how the required fields will be displayed.  
  
−
<div class="mw-collapsible mw-collapsed" data-collapsetext="Show Less" data-expandtext="Read More" style="width:800px">
+
:* '''Request Actions'''
−
:* Portal Head's Up Display (HUD)
+
[[File:Request_Actions.png|right|500px|Link=]]
−
<div class="mw-collapsible-content">
+
:: Define which Actions are available to users on the Request Action bar when working on requests raised against the Service. 
−
[[File:HUD_Portal.png|center|800px]]
+
 
−
:: When a business process is defined and supporting either the Incident or Service Request request types, it is possible to define what level of visibility you wish to give to your customers of the processes progress through a graphical head's up
+
:: An example being you may choose not to enable the 'Escalation' Action against Service Requests if you are not using Priorities for requests of this type for a particular Service.  However you have this available for Incidents and Problems where you have chosen to use priorities for those request types.
−
:: display.  It is possible to give no visibility, top level or a granular view per request type and per service via either the Service and Customer Portals.
 
  
−
:: The default option is '''Off'''.
+
:::* Enable or Disable an Action by clicking on the Action Icon for each Request type
 +
:::* Hover over each Action Icon to see a tooltip with the Action's purpose.
 +
:::* Globally manage which Action items are enabled when a request is on-hold through '''[[Request Settings]]'''
  
−
:::* '''Off''' - No graphical representation of the supporting business process will be displayed on the request forms on either the Service or Customer Portal
+
:* '''Request Categories'''
−
:::* '''Stages Only''' - Top level visibility of each of the defined stages will be displayed at the top of the request forms on the Service and Customer Portals.   This will allow the subscribed customers to see the stages which have been completed and those which are still outstanding.
+
[[File:Service_Categories.png|right|500px|Link=]]
−
:::* '''Stages and Checkpoints''' -  This will show both the process stages and the defined checkpoints for each stage.  This will give the subscribed customers the same level of visibility of the requests progress as the analysts see, and will allow them to see which stages and checkpoints have been completed and what is still outstanding to complete.
+
:: 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>
 +
</div>
 
</div>
 
</div>
 
</div>
 
</div>
−
<div class="mw-collapsible-content"><div class="mw-collapsible-content"><div class="mw-collapsible mw-collapsed" data-collapsetext="Show Less" data-expandtext="Read More" style="width:800px">
+
 
−
:* Request Actions
+
:* '''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]]'''
 +
:: 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>
 +
 
 +
== [[File:Knownerroricon.png|25px|link=|Known Error]] Known Error ==
 +
<div style="width:73%">
 +
:* '''Known Error Configuration'''
 +
<div class="mw-collapsible mw-collapsed" data-collapsetext="Show Less" data-expandtext="Read More">
 +
:: Setup and configure Known Errors for this Service.
 
<div class="mw-collapsible-content">
 
<div class="mw-collapsible-content">
−
[[File:Request_Actions.png|center]]
+
<div style="border:1px solid #e6e6e6; background:#f2f2f2; width:99%; padding:4px; margin-bottom:10px;">
 +
:* '''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.
 +
:* '''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. 
 +
 
 +
:* '''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.
 +
 
 +
:* '''Form Designer'''
 +
:: It is possible for you to define custom fields to use against each request type per service.  Using the form designer you can edit which default fields will be displayed in the '''Details''' section of each request form, as well as add new fields, set field  validation, configure mandatory options and using drag and drop to re-order how the required fields will be displayed.  
  
−
:: Define which actions are available to analysts working on requests raised against the Service.  It is possible to configure which Action Icons will appear on the Action Bar on the different request forms for each Service.  It is possible to configure different Actions per request type per Service.
+
:* '''Request Actions'''
 +
[[File:Request_Actions.png|right|500px|Link=]]
 +
:: Define which Actions are available to users on the Request Action bar when working on requests raised against the Service.   
  
 
:: An example being you may choose not to enable the 'Escalation' Action against Service Requests if you are not using Priorities for requests of this type for a particular Service.  However you have this available for Incidents and Problems where you have chosen to use priorities for those request types.
 
:: An example being you may choose not to enable the 'Escalation' Action against Service Requests if you are not using Priorities for requests of this type for a particular Service.  However you have this available for Incidents and Problems where you have chosen to use priorities for those request types.
  
−
::* The Default position is all Actions Icons are available for all request types
+
:::* Enable or Disable an Action by clicking on the Action Icon for each Request type
−
::* Enable or Disable an Action by clicking on the Action Icon for each Request type
+
:::* Hover over each Action Icon to see a tooltip with the Action's purpose.
−
::* Hover over each Action Icon to see a tooltip with the Actions purpose.
+
:::* Globally manage which Action items are enabled when a request is on-hold through '''[[Request Settings]]'''
 +
 
 +
:* '''Request Categories'''
 +
[[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.
 +
::'''Note:''' If the Category Level is filtered to the last level on a branch, no Categories will be visible for selection.
 +
<BR>
 
</div>
 
</div>
 
</div>
 
</div>
−
<div class="mw-collapsible-content"><div class="mw-collapsible-content"><div class="mw-collapsible mw-collapsed" data-collapsetext="Show Less" data-expandtext="Read More" style="width:800px">
+
</div>
−
:* Request Categories
+
 
 +
:* '''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]]'''
 +
:: 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>
 +
 
 +
== [[File:Changeicon.png|25px|link=|Change]] Change ==
 +
<div style="width:73%">
 +
:* '''Change Configuration'''
 +
<div class="mw-collapsible mw-collapsed" data-collapsetext="Show Less" data-expandtext="Read More">
 +
:: Setup and configure Change Management for this Service.
 
<div class="mw-collapsible-content">
 
<div class="mw-collapsible-content">
−
[[File:Service_Categories.png|center]]
+
<div style="border:1px solid #e6e6e6; background:#f2f2f2; width:99%; padding:4px; margin-bottom:10px;">
−
:: 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 requests against each Service.
+
:* '''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.
 +
:* '''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 default position is to use the root of the category tree for all request types against all Services.
+
:* '''Email Template'''
−
::* Configure a different starting level per request type for each service by clicking on either the '''Category Level''' or '''Resolution Category Level''' options and choosing a different starting level.
+
:: 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.
−
::* Once configured only child levels of the category tree will be presented when adding a category to a request via Progressive Capture or the Request Details forms.  
+
 
 +
:* '''Form Designer'''
 +
:: It is possible for you to define custom fields to use against each request type per service.  Using the form designer you can edit which default fields will be displayed in the '''Details''' section of each request form, as well as add new fields, set field  validation, configure mandatory options and using drag and drop to re-order how the required fields will be displayed.
 +
 
 +
:* '''Portal Process Tracker'''
 +
[[File:HUD_Portal.png|right|500px|link=]]
 +
:: When a Business Process Workflow is being used to support either the Service Requests or Incidents, it is possible to define what level of visibility you wish to give to your customers of the Process Tracker.
 +
:::* '''Off''' - The Process Tracker is hidden from customers.
 +
:::* '''Stages Only''' - Only the top level of the Process Tracker that shows the stages will be displayed.
 +
:::* '''Stages and Checkpoints''' -  This will show both the Stages and the checkpoints.
 +
 
 +
:* '''Request Actions'''
 +
[[File:Request_Actions.png|right|500px|Link=]]
 +
:: Define which Actions are available to users on the Request Action bar when working on requests raised against the Service. 
 +
 
 +
:: An example being you may choose not to enable the 'Escalation' Action against Service Requests if you are not using Priorities for requests of this type for a particular Service.  However you have this available for Incidents and Problems where you have chosen to use priorities for those request types.
 +
 
 +
:::* Enable or Disable an Action by clicking on the Action Icon for each Request type
 +
:::* Hover over each Action Icon to see a tooltip with the Action's purpose.
 +
:::* Globally manage which Action items are enabled when a request is on-hold through '''[[Request Settings]]'''
 +
 
 +
:* '''Request Categories'''
 +
[[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.
 +
::'''Note:''' If the Category Level is filtered to the last level on a branch, no Categories will be visible for selection.
 +
<BR>
 
</div>
 
</div>
 
</div>
 
</div>
 +
</div>
 +
:* '''[[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.
 +
 +
:* '''[[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.
 +
</div>
 +
 +
== [[File:Releaseicon.png|25px|link=|Release]] Release ==
 +
<div style="width:73%">
 +
:* '''Release Configuration'''
 +
<div class="mw-collapsible mw-collapsed" data-collapsetext="Show Less" data-expandtext="Read More">
 +
:: Setup and configure Release Management for this Service.
 +
<div class="mw-collapsible-content">
 +
<div style="border:1px solid #e6e6e6; background:#f2f2f2; width:99%; padding:4px; margin-bottom:10px;">
 +
:* '''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.
 +
:* '''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. 
 +
 +
:* '''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.
  
−
== [[Request Catalog |Catalog Items]] ==
+
:* '''Form Designer'''
−
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:
+
:: It is possible for you to define custom fields to use against each request type per service.  Using the form designer you can edit which default fields will be displayed in the '''Details''' section of each request form, as well as add new fields, set field  validation, configure mandatory options and using drag and drop to re-order how the required fields will be displayed.  
  
−
::[[Request Catalog| Read more... ]]
+
:* '''Portal Process Tracker'''
 +
[[File:HUD_Portal.png|right|500px|link=]]
 +
:: When a Business Process Workflow is being used to support either the Service Requests or Incidents, it is possible to define what level of visibility you wish to give to your customers of the Process Tracker.
 +
:::* '''Off''' - The Process Tracker is hidden from customers.
 +
:::* '''Stages Only''' - Only the top level of the Process Tracker that shows the stages will be displayed.  
 +
:::* '''Stages and Checkpoints''' -  This will show both the Stages and the checkpoints.
  
−
== [[Customer Feedback]] ==
+
:* '''Request Actions'''
−
The Customer Feedback options provides a feature to gather feedback from your customers regarding the level of service they have received for a particular request.  This feedback will enable you to identify where excellent service is already being provided, but also highlight any areas where the service to your customers could be improved.   
+
[[File:Request_Actions.png|right|500px|Link=]]
 +
:: Define which Actions are available to users on the Request Action bar when working on requests raised against the Service.   
  
−
::[[Customer Feedback|Read more...]]
+
:: An example being you may choose not to enable the 'Escalation' Action against Service Requests if you are not using Priorities for requests of this type for a particular Service. However you have this available for Incidents and Problems where you have chosen to use priorities for those request types.
  
−
== Sub-Statuses ==
+
:::* Enable or Disable an Action by clicking on the Action Icon for each Request type
−
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 will place the request's status to On-hold and stop any allocated Service Level Target timers.
+
:::* Hover over each Action Icon to see a tooltip with the Action's purpose.
 +
:::* Globally manage which Action items are enabled when a request is on-hold through '''[[Request Settings]]'''
  
−
::[[Request Sub-statuses|Read more...]]
+
:* '''Request Categories'''
 +
[[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.
 +
::'''Note:''' If the Category Level is filtered to the last level on a branch, no Categories will be visible for selection.
 +
<BR>
 +
</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]]'''
 +
:: 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>
 +
[[Category:Service Manager]]

Revision as of 20:21, 11 April 2024

Home > Service Manager > Service Portfolio > Service Details > Services Request Configuration

Introduction

The Service Request Configuration lets you define a number of elements for the different request types that are used for each Service. This allows each Service to provide its own experience for both the Support Staff and the subscribed customers.

Related Articles

Incident Incident

Incident Configuration

Setup and configure Incident Management for this Service.
  • 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.
  • Workflow
The Workflow is an optional setting that allows you to associate a workflow which will be used as the default Workflow for all Incidents 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.
  • 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.
  • Form Designer
It is possible for you to define custom fields to use against each request type per service. Using the form designer you can edit which default fields will be displayed in the Details section of each request form, as well as add new fields, set field validation, configure mandatory options and using drag and drop to re-order how the required fields will be displayed.
  • Portal Process Tracker
HUD Portal.png
When a Business Process Workflow is being used to support either the Service Requests or Incidents, it is possible to define what level of visibility you wish to give to your customers of the Process Tracker.
  • Off - The Process Tracker is hidden from customers.
  • Stages Only - Only the top level of the Process Tracker that shows the stages will be displayed.
  • Stages and Checkpoints - This will show both the Stages and the checkpoints.
  • Request Actions
Link=
Define which Actions are available to users on the Request Action bar when working on requests raised against the Service.
An example being you may choose not to enable the 'Escalation' Action against Service Requests if you are not using Priorities for requests of this type for a particular Service. However you have this available for Incidents and Problems where you have chosen to use priorities for those request types.
  • Enable or Disable an Action by clicking on the Action Icon for each Request type
  • Hover over each Action Icon to see a tooltip with the Action's purpose.
  • Globally manage which Action items are enabled when a request is on-hold through Request Settings
  • Request Categories
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.
Note: If the Category Level is filtered to the last level on a branch, no Categories will be visible for selection.


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.
The Customer Feedback options provides a feature to gather feedback from your customers regarding the level of service they have received for a particular request. This feedback will enable you to identify where excellent service is already being provided, but also highlight any areas where the service to your customers could be improved.
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.

Request Request

  • Request Configuration
Setup and configure Request Management for this Service.
  • 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.
  • 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.
  • 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.
  • Form Designer
It is possible for you to define custom fields to use against each request type per service. Using the form designer you can edit which default fields will be displayed in the Details section of each request form, as well as add new fields, set field validation, configure mandatory options and using drag and drop to re-order how the required fields will be displayed.
  • Portal Process Tracker
HUD Portal.png
When a Business Process Workflow is being used to support either the Service Requests or Incidents, it is possible to define what level of visibility you wish to give to your customers of the Process Tracker.
  • Off - The Process Tracker is hidden from customers.
  • Stages Only - Only the top level of the Process Tracker that shows the stages will be displayed.
  • Stages and Checkpoints - This will show both the Stages and the checkpoints.
  • Request Actions
Link=
Define which Actions are available to users on the Request Action bar when working on requests raised against the Service.
An example being you may choose not to enable the 'Escalation' Action against Service Requests if you are not using Priorities for requests of this type for a particular Service. However you have this available for Incidents and Problems where you have chosen to use priorities for those request types.
  • Enable or Disable an Action by clicking on the Action Icon for each Request type
  • Hover over each Action Icon to see a tooltip with the Action's purpose.
  • Globally manage which Action items are enabled when a request is on-hold through Request Settings
  • Request Categories
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.
Note: If the Category Level is filtered to the last level on a branch, no Categories will be visible for selection.


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.
The Customer Feedback options provides a feature to gather feedback from your customers regarding the level of service they have received for a particular request. This feedback will enable you to identify where excellent service is already being provided, but also highlight any areas where the service to your customers could be improved.
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.

Problem Problem

  • Problem Configuration
Setup and configure Problem Management for this Service.
  • 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.
  • 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.
  • 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.
  • Form Designer
It is possible for you to define custom fields to use against each request type per service. Using the form designer you can edit which default fields will be displayed in the Details section of each request form, as well as add new fields, set field validation, configure mandatory options and using drag and drop to re-order how the required fields will be displayed.
  • Request Actions
Link=
Define which Actions are available to users on the Request Action bar when working on requests raised against the Service.
An example being you may choose not to enable the 'Escalation' Action against Service Requests if you are not using Priorities for requests of this type for a particular Service. However you have this available for Incidents and Problems where you have chosen to use priorities for those request types.
  • Enable or Disable an Action by clicking on the Action Icon for each Request type
  • Hover over each Action Icon to see a tooltip with the Action's purpose.
  • Globally manage which Action items are enabled when a request is on-hold through Request Settings
  • Request Categories
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.
Note: If the Category Level is filtered to the last level on a branch, no Categories will be visible for selection.


  • 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.
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.

Known Error Known Error

  • Known Error Configuration
Setup and configure Known Errors for this Service.
  • 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.
  • 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.
  • 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.
  • Form Designer
It is possible for you to define custom fields to use against each request type per service. Using the form designer you can edit which default fields will be displayed in the Details section of each request form, as well as add new fields, set field validation, configure mandatory options and using drag and drop to re-order how the required fields will be displayed.
  • Request Actions
Link=
Define which Actions are available to users on the Request Action bar when working on requests raised against the Service.
An example being you may choose not to enable the 'Escalation' Action against Service Requests if you are not using Priorities for requests of this type for a particular Service. However you have this available for Incidents and Problems where you have chosen to use priorities for those request types.
  • Enable or Disable an Action by clicking on the Action Icon for each Request type
  • Hover over each Action Icon to see a tooltip with the Action's purpose.
  • Globally manage which Action items are enabled when a request is on-hold through Request Settings
  • Request Categories
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.
Note: If the Category Level is filtered to the last level on a branch, no Categories will be visible for selection.


  • 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.
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.

Change Change

  • Change Configuration
Setup and configure Change Management for this Service.
  • 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.
  • 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.
  • 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.
  • Form Designer
It is possible for you to define custom fields to use against each request type per service. Using the form designer you can edit which default fields will be displayed in the Details section of each request form, as well as add new fields, set field validation, configure mandatory options and using drag and drop to re-order how the required fields will be displayed.
  • Portal Process Tracker
HUD Portal.png
When a Business Process Workflow is being used to support either the Service Requests or Incidents, it is possible to define what level of visibility you wish to give to your customers of the Process Tracker.
  • Off - The Process Tracker is hidden from customers.
  • Stages Only - Only the top level of the Process Tracker that shows the stages will be displayed.
  • Stages and Checkpoints - This will show both the Stages and the checkpoints.
  • Request Actions
Link=
Define which Actions are available to users on the Request Action bar when working on requests raised against the Service.
An example being you may choose not to enable the 'Escalation' Action against Service Requests if you are not using Priorities for requests of this type for a particular Service. However you have this available for Incidents and Problems where you have chosen to use priorities for those request types.
  • Enable or Disable an Action by clicking on the Action Icon for each Request type
  • Hover over each Action Icon to see a tooltip with the Action's purpose.
  • Globally manage which Action items are enabled when a request is on-hold through Request Settings
  • Request Categories
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.
Note: If the Category Level is filtered to the last level on a branch, no Categories will be visible for selection.


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.
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.

Release Release

  • Release Configuration
Setup and configure Release Management for this Service.
  • 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.
  • 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.
  • 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.
  • Form Designer
It is possible for you to define custom fields to use against each request type per service. Using the form designer you can edit which default fields will be displayed in the Details section of each request form, as well as add new fields, set field validation, configure mandatory options and using drag and drop to re-order how the required fields will be displayed.
  • Portal Process Tracker
HUD Portal.png
When a Business Process Workflow is being used to support either the Service Requests or Incidents, it is possible to define what level of visibility you wish to give to your customers of the Process Tracker.
  • Off - The Process Tracker is hidden from customers.
  • Stages Only - Only the top level of the Process Tracker that shows the stages will be displayed.
  • Stages and Checkpoints - This will show both the Stages and the checkpoints.
  • Request Actions
Link=
Define which Actions are available to users on the Request Action bar when working on requests raised against the Service.
An example being you may choose not to enable the 'Escalation' Action against Service Requests if you are not using Priorities for requests of this type for a particular Service. However you have this available for Incidents and Problems where you have chosen to use priorities for those request types.
  • Enable or Disable an Action by clicking on the Action Icon for each Request type
  • Hover over each Action Icon to see a tooltip with the Action's purpose.
  • Globally manage which Action items are enabled when a request is on-hold through Request Settings
  • Request Categories
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.
Note: If the Category Level is filtered to the last level on a branch, no Categories will be visible for selection.


  • 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.
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.
Retrieved from "https://wiki.hornbill.com/index.php?title=Services_Request_Configuration&oldid=32317"