Difference between revisions of "Progressive Capture Workflow"

From Hornbill
Jump to navigation Jump to search
Line 31: Line 31:
 
::Default when raising a change
 
::Default when raising a change
  
−
 
−
<div class="mw-collapsible mw-collapsed" data-collapsetext="Show Less" data-expandtext="Read More" style="width:1000px">
 
−
 
−
==Sharing and Visibility==
 
−
 
−
Progressive capture owners will be able to view their own captures, and captures which have been shared with them from the Progressive Capture  List. 
 
−
 
−
When creating or editing a capture it is possible via the '''Manage Process Settings''' and '''Grant Access To''' option to share your process with:
 
−
 
−
* Roles
 
−
* Users
 
−
* Groups - Configured via the Organisational group structure
 
−
 
−
It is possible to share captures with multiple users, roles and groups.  Once a capture has been shared, the user will be able to view the capture from the '''Progressive Capture''' list.
 
−
 
−
To remove visibility to a specific User, Role or Group simply select the '''Trash Can''' icon next to the item you wish to stop sharing the capture with.
 
−
 
−
To enforce the above sharing and visibility controls, ensure the system setting '''security.bpm_access_controls.enabled''' is set to '''On''' from the administration console:
 
−
* Home > System > Settings > Advanced
 
−
 
−
==Branches==
 
−
 
−
In progressive capture, branches allow the workflow designer to send the analyst down different routes to potentially collect different information depending on the choices that are made on progressive capture forms. It is important to remember that a branch node will always inherit the outcomes from its parent progressive capture forms. This means that if you place a branch node after the request details form (as shown in the below screenshot), the only pieces of data that you can make a decision on are the Summary and Description fields (only 2 fields on this default form).
 
−
<div class="mw-collapsible-content">
 
−
[[File:pcf_decision1.png |800px|decision node based on request summary]]  [[File:pcf_decision2.png |500px|decision node based on request summary]] 
 
−
 
−
To add a custom expression to a decision node you must first connect the decision node to the next node in the flow. You can then click the linking line and define your custom expression. You can define multiple outcomes from a decision node, however you must always have at least one valid outcome, otherwise the progressive capture flow could potentially have nowhere to go which will make it error.
 
−
 
−
[[File:pcf_decision3.png |800px|multiple outcomes]]  [[File:pcf_decision4.png |800px|no match decision]]
 
−
</div>
 
−
</div>
 
−
 
−
==Switch Process==
 
−
 
−
In Progressive Capture the Switch Process node provides the ability to seamlessly move to or link Progressive Capture flows together.  One example of where this maybe useful is in Service Manager when choosing a Request Catalog item from the '''Services''' Progressive Capture form, the switch process can be used to switch to the the Progressive Capture flow which is assigned to the chosen Request Catalog item.
 
−
 
−
Using this node replaces the previous behaviour of jumping from an initial progressive capture to another, and in essence any forms used in both are evaluated and re-used when jumping, it also removes the need to evaluate which forms in the second progressive capture to use, and any issues associated with progressive capture forms being skipped.
 
−
 
−
Using this node, will in effect continue from the initial progressive capture, into the next progressive capture rather than replace it.  This means it does not need to evaluate which forms to skip, it simply ignores any forms already used in the initial progressive capture.
 
−
 
−
Advantages of using the Switch Process Node
 
−
 
−
* When switching processes the UI for the analyst is  smooth as you are linking one process to another not replacing one with another
 
−
* The ability to return / revisit the forms in the initial process capture flow, once you have switched or linked to a second process capture flow in order to change values / choices or even change which progressive capture to switch / link too.
 
−
* You don't need to include the same forms in both Progressive Captures, for example the Customer Search form could just be used in the initial progressive capture, and removed from the catalog item progressive capture (obviously if it already exists it will simply be ignored).
 
−
 
−
'''Example'''  [[File:SwitchProcessConfig.png|right|thumb]]
 
−
 
−
Following the use of the Services Details form, you may include a '''Branch''' node, and have two outcomes.
 
−
* 1.  Using a Custom Expression, perform a check to see if ''''Service details -> catalogProgressiveCaptureId''' '''Is Set''' (if a request catalog item has been selected)  from here link to the '''Switch Process''' node
 
−
* 2.  Using another Custom Expression perform the same check but set this to '''Is Not Set''' (a Service rather than a request catalog item has been selected) and build your logic accordingly, equally you could define multiple other outcomes from this branch node to reflect the different service choices and paths you wish to take.
 
−
 
−
On the Switch Process node, you can configure this to link to a specific new process, or use a '''Variable''' to link to the progressive capture linked to the request catalog item which has been chosen.  In this example this is what we will do and the Variable to use would be '''Service details -> catalogProgressiveCaptureId'''
 
−
 
−
* '''Note:''' with the introduction of the Switch Process option, the behaviour will alter slightly on the '''Services Details''' form, is as much as the user will now have to select the '''Next''' button if they are selecting either the Service or the Request Catalog Item in order to progress the progressive capture.  Previously if a Request Catalog Item was chosen the progressive capture would immediately progress without the need to click '''Next'''.
 
−
 
−
 
−
<div class="mw-collapsible mw-collapsed" data-collapsetext="Show Less" data-expandtext="Read More" style="width:1000px">
 
  
 
==Default Forms (PCF's)==
 
==Default Forms (PCF's)==

Revision as of 23:48, 12 December 2016

Home > Administration > Service Manager > Progressive Capture

Introduction

Progressive Capture allows you to configure how and what information is collected or captured when a request is being raised. This includes default capture forms that are specific to Service Manager and the ability to create custom question forms.

Related Articles

Settings

Service Manager settings are available to configure the default Progressive Captures that are used when raising requests.

  • app.itsm.progressiveCapture.newRequest
The named Progressive capture on this setting will be used when the Raise New option is used or when an email is used to raise a new request
  • app.itsm.progressiveCapture.newIncident
The named Progressive capture on this setting will be used when raising an Incident
  • app.itsm.progressiveCapture.newServiceRequest
The named progressive capture on this setting will be used
  • app.itsm.progressiveCapture.newProblem
Default when raising problems
  • app.itsm.progressiveCapture.newKnownError
Default when raising Known Errors
  • app.itsm.progressiveCapture.newChange
Default when raising a change


Default Forms (PCF's)

Hornbill provide a number of default progressive capture forms that are available to use right out of the box. These forms are listed alphabetically below:

Add Attachments

The 'Add Attachments' PCF allows an analyst to add attachments when raising a request. Multiple attachments can be provided and individual descriptions can be applied to each file:

progressive capture designer form properties

Analyst view when logging a request:
user application

Analyst Assignment

The 'Analyst Assignment' PCF allows an analyst to select the team and owner of the request. An analyst can choose to assign the request to just a team or to a team and a specified analyst:

progressive capture designer form properties

Analyst view when logging a request:
user application

Analyst Request Type

The 'Analyst Request Type' PCF allows an analyst to choose the type of request that will be created. This PCF form is most commonly seen in the 'New Request' progressive capture flow as the analyst may not know which type of request needs to be raised when they first start capturing information:

progressive capture designer form properties

Analyst view when logging a request:
user application

Asset Details

The 'Asset Details' PCF allows an analyst to associate assets to the request. By default, all assets that are associated to the customer of the request are shown however it is also possible to perform a general search on assets that are in the system. It's possible to associate multiple assets to each request:

progressive capture designer form properties

Analyst view when logging a request:
user application user application

Change Type

The 'Change Type' PCF allows an analyst to select the type of change request that will be raised. This PCF is usually only seen on the new Change progressive capture flow:

progressive capture designer form properties

Analyst view when logging a request:
user application

Customer Request Type

The 'Customer Request Type' PCF allows the customer to choose what type of request they are raising. This PCF is most commonly seen on the 'New Self Service' progressive capture flow which is used by both the Hornbill Service and Customer portals. It is slightly different to the PCF 'Analyst Request Type' in that it only offers the ability to select a request type of Incident (Something is broken) or Service Request (I need something):

progressive capture designer form properties

Customer view when logging a request:
user application

Customer Search

The 'Customer Search' PCF allows an analyst to select a customer for the request:

progressive capture designer form properties

Analyst view when logging a request:
user application

Known Error Details

The 'Known Error Details' PCF allows an analyst to specify root cause and workaround details for a known error. This PCF is usually only seen on the new Known Error progressive capture flow:

progressive capture designer form properties

Analyst view when logging a request:
user application

Organisation Details

The 'Organisation Details' PCF allows an analyst to see additional information about the customer's organisation that is defined by a Hornbill administrator. There is no data captured in this PCF - it is purely informational only:

progressive capture designer form properties form properties

Analyst view when logging a request:
user application

Request Category

The 'Request Category' PCF allows an analyst to specify a category when logging a request.

progressive capture designer form properties

Analyst view when logging a request:
user application

Request Details

The 'Request Details' PCF allows an analyst to enter both a summary and a description for the request:

progressive capture designer form properties

Analyst view when logging a request:
user application

Request Priority

The 'Request Priority' PCF allows an analyst to set the priority of the request:

progressive capture designer form properties

Analyst view when logging a request:
user application

Service Details

The 'Service Details' PCF allows an analyst to specify a service when logging a request:

progressive capture designer form properties

Analyst view when logging a request:
user application

Default Form Configuration

Default forms can be customised

When selecting a default Hornbill PCF there are two ways in which you can customise it:

  1. Mark as Mandatory - Setting this option to true means that a value or values will need to be provided by the analyst before they can advance to the next progressive capture form. The default setting for each form is false. Mandatory fields are indicated by the vertical red bar on the left edge of the field. If a field is required and you attempt to move to the next PCF without providing a value, you will be shown an error message.

mandatory setting in the progressive capture designer mandatory setting enforced in the user app

2. Define Additional Display Fields - Certain PCF's have the ability to display additional information such as the Organisation Details and Customer Search forms. A Hornbill administrator can select which additional data is displayed when an analyst selects a value from the selected progressive capture form.

In the progressive capture designer additional display fields shown in the user app

Customised Forms

As well as standard forms, Hornbill also provide the ability to create your own custom forms. With custom forms, you can create multiple questions of different field types for analysts to answer during progressive capture. This feature is particularly useful for new starter/leaver processes as the progressive capture workflow designer is able to ask for the exact pieces of information that they require for their process.

New - A Never Skip configuration option has been added, which can be set to True, this will ensure that this form is never bypassed in your progressive capture flow, even if custom questions have default values set, and the questions are not set to mandatory. This will ensure the user will always be presented with the form to at least validate the default choices, or change them if required.

New PC Custom Form.png

With each custom form, it is a good idea to give it a unique form id so that you can identify the answers to your questions later on when using the Hornbill Business Process Workflow engine. The Form Prompt is the piece of text that the user will see when they get to the custom PCF when logging a new request:

form properties including form id and form prompt form prompt text in user app

When adding fields to custom forms, there are several configuration options to consider. You can for example, mark a field as mandatory, read only, and include it as part of the summary. There are also multiple field types to choose from including single text fields, a multi line text field, selection boxes and date/time pickers:

form properties - static drop down selection box form properties - date time picker form properties - multi line text input form summary in user app

Analyst view when logging a request:

Custom PCF in user app Custom PCF in user app

Mapping Fields from Customised Forms

When creating customised forms, and custom questions the default behaviour is for the question and answer to be visible on the request form in a Questions collapsable section. It is also possible to map the answer from a custom question to one of the default fields on a request.

When creating a custom question on a customised form, each question will require a Field ID to be specified, it is here that the mapping can be performed. When defining the Field ID, if you use any of the following values, the answer to this question will be mapped to the field you have specified.

Mapping Custom Fields.png

Available Fields to Map to

  • Summary - To map to this field the Field ID needs to be set as h_summary
  • Description - To map to this field the Field ID needs to be set as h_description
  • Custom Fields a - p - To map to any of the custom fields the Field ID need to be set using the following format h_custom_a or appropriate for the custom field you would like to map too.

When custom questions have been mapped to a default request field, the question and answer are still available in the Questions section on a request as well as the default fields mapped too.

  • This will allow for the original answer to be retained
  • The default fields values can be changed once logged

Considerations

  • If the Default Request Details form is used in your progressive capture flow, and you try to map to h_summary or h_description, the values will not overwrite or be written to the summary or description fields, but the custom questions and answers will still be written to the Questions section on the request.
  • If the same mapping is used on different custom forms in your progressive capture flow, the first mapping will be written to the specified default field on the request, and any subsequent mapping to the same field will not overwrite this value, but will be written to the Questions section on the request.

Using Custom Questions and Answers in Email Templates

If you have a requirement to include the answers to custom questions in email templates within your business process, it is now possible to utilise the above mapping to write the answers to the custom questions into default fields which are immediately available to use as variables when creating your email templates.

By using the above mapping to any of the requests custom fields, when creating your email template, simply look for the Extended Information options available from the variables drop down pick list. They will look like this: {{Extended Information.H_custom_x}}. The Extended Information options are listed as 1 through to 20 and these equate to the custom fields a through to p which you will have mapped to. By selecting the required variable in your email template, this will pass through the answer from your custom question which has been mapped to the corresponding custom field.

Hornbill Default Progressive Capture Flows

By default, Hornbill provide the following seven progressive capture flows. These can be edited, copied or deleted accordingly:

New Request

new request progressive capture flow

New Self Service

new self service progressive capture flow

New Incident

new incident progressive capture flow

New Service Request

new service request progressive capture flow

New Problem

new problem progressive capture flow

New Change Request

new change request progressive capture flow

New Known Error

new known error progressive capture flow

Retrieved from "https://wiki.hornbill.com/index.php?title=Progressive_Capture_Workflow&oldid=11265"