Documentation

    {{docApp.userSession.userId}}
    {{docApp.userSession.userName}}
    {{docApp.userSession.email}}
    Issuer : {{docApp.userSession.issuerInstance}}
    Expires : {{new Date(docApp.userSession.validUntil).toLocaleDateString()}}

{{docApp.title}}

{{docApp.description}}

How can we help?

{{docApp.searchError}}
{{product.name}}

Searching in {{docApp.searchFilterBySpecificBookTitle}}

{{docApp.searchResultFilteredItems.length}} results for: {{docApp.currentResultsSearchText}} in {{docApp.searchFilterBySpecificBookTitle}}
Search results have been limited. There are a total of {{docApp.searchResponse.totalResultsAvailable}} matches.

You have an odd number of " characters in your search terms - each one needs closing with a matching " character!

{{docApp.libraryHomeViewProduct.title || docApp.libraryHomeViewProduct.id}}

{{docApp.libraryHomeViewProduct.description}}

  1. {{book.title}}

{{group.title || group.id}}

{{group.description}}

  1. {{book.title}}

{{group.title}}

{{book.title}}
More...

Application Settings

You can configure the various application settings associated with Hornbill Service Manager in Configuration > Service Manager > Advanced Tools and Settings > Application Settings.

This document describes some of the more commonly used settings. This is not a complete list.

Before you begin

Accessing Application Settings

You install Hornbill apps from the Hornbill App Store, which you access through Configuration.

To access the Hornbill App Store:

  1. Open Configuration using the cog at the bottom of the left-hand menu bar (or with CTRL+SHIFT+S on your keyboard).
  2. Click the down arrow next to My Personal Settings, then select Service Manager.
  3. In the navigation panel, scroll down to Advanced Tools & Settings.
  4. Select Application Settings.

Using filters

At the top of the settings list, there are some options available to help you find the settings you are looking for.

Advanced Settings

Because advanced settings are less frequently used and potentially more complex to change, by default, they are not displayed in the list. If you are unable to find a particular setting, you may find that it is classed as an advanced setting. Select Include advanced settings to make sure even less frequently used settings are visible in the list.

Email settings

Archiving emails

The following setting can be used to automatically move an email into a folder of your choice after a request has been manually raised from the email. Moving an email to a designated folder will help prevent other users from raising duplicate requests from the same email.

servicemanager.email.archiveFolderName

  • The default folder name for this is Deleted Items.
  • This setting applies to all shared mailboxes that Service Manager users have access to.

Email authorization

An email can be sent to a user that is assigned an authorization task. To receive and process the email authorization, the user must be a full user (not a Basic user).

app.request.sendEmailToAuthorizers

  • The default setting for this is OFF.

guest.app.authorizations.email.revealOutcomes

  • The default setting for this is ON.
  • When set to ON, an option to accept or reject the authorization is included as part of the authorization email.
  • Turning this setting to OFF removes the accept/reject option. The user will only have the option to click a link to view the authorization in Hornbill.

Email Request On-Hold Update to Customer

An email can be sent to a customer of a request when their request is either place on-hold or taken off-hold.

guest.app.requests.notificaiton.emailTemplate.customerRequestOnHoldUpdate

  • Specifies the name of the email template that will be used.
  • The default template for this feature is called CustomerRequestOnHoldUpdate.

Category settings

servicemanager.request.closureCategory.default.enabled

  • The default setting for this is OFF.
  • When this setting is ON, the resolution category is mandatory for all requests.
  • If there are no defined closure categories, this setting is ignored.

Portal settings

guest.servicemanager.customer.request.showHistoricUpdates

  • The default setting for this is OFF.
  • When this setting is ON, users of the Customer Portal will be able to see an additional collapsible panel on their Requests view that contains any related historical request-update data that may have been imported from a previous service management tool. This section is only visible on imported requests.

guest.servicemanager.portal.request.showHistoricUpdates

  • The default setting for this is OFF.
  • When this setting is ON, users of the Employee Portal will be able to see an additional collapsible panel on their requests view that contains any related historical request-update data that may have been imported from a previous service management tool. This section is only visible on imported requests.

servicemanager.portal.requests.showStaffRequests

  • The default setting for this is OFF.
  • When this setting is ON, managers are able to view requests raised by their direct staff via the Employee Portal. (The manager is the named user who is populated in the Manager field on a user’s profile.)

guest.servicemanager.portal.request.enableServiceRequestCancellation

  • The default setting for this is OFF.
  • When this setting is ON, users of the Customer Portal will be able to cancel their service requests if no longer needed.
  • The owner or team of the service request can receive an email, a Hornbill notification — or both — informing them of the cancellation.
  • Customers must be assigned the Self Service Request Cancel User role in order to use this feature.

guest.servicemanager.customer.request.enableServiceRequestCancellation

  • The default setting is OFF.

  • When the setting is ON, guests are able to cancel their service requests from within the Customer Portal.

  • The owner or team of the service request can receive an email, a Hornbill notification — or both — informing them of the cancellation.

  • Customers must be enabled to use this feature via the Portal Access option available in Organization > Details > Request tab.

    To enable this cancellation feature:

    1. When viewing the details of an organization, scroll down and expand the Requests section.
    2. At the top right, click Portal Access.
    3. In the Customer Portal Access dialog, toggle settings for portal users as needed.

guest.servicemanager.portal.additionalRequestTypes.change

  • The default is OFF.
  • When this setting is OFF, customers cannot see changes on the portals’ requests lists, nor can they see any configured portal-visible change catalog items.
  • When this setting is ON, customers can see all new and historic change records in the request lists on the portals where they are the marked as the customer.
  • When this setting is ON, customers have the option to see and use portal-visible change catalog items for their subscribed services.

guest.com.hornbill.servicemanager.showRespondByDate

  • The default is OFF.
  • When this setting is ON, the respond by date/time is displayed in the right-hand information box of a request when viewed by a user on the Employee Portal or a customer on the Customer Portal.

guest.com.hornbill.servicemanager.showResolveByDate

  • The default is OFF
  • When this setting is ON, the resolve by date/time is displayed in the right-hand information box of a request when viewed by a user on the Employee Portal or a customer on the Customer Portal.

Intelligent Capture settings

Service Manager forms

Only show supported and subscribed services servicemanager.progressiveCapture.servicedetails.enableSupportVisibility

  • The default setting for this is OFF.
  • When this setting is ON, the services displayed on the Services form are filtered to both those which the customer is subscribed to, and also to those services which the Service Manager user supports.

Only show supported requests app.itsm.progressiveCapture.customerDetails.showOnlySupportedRequests

  • The default setting for this is OFF.
  • This setting determines whether a Service Manager user is granted visibility to unsupported customer requests in the Customer Search, Contact Search, or Co-worker Search forms in Intelligent Capture.
  • When set to OFF, a Service Manager user has visibility to unsupported customer requests. This should be set to ON in environments with multiple service desks (e.g. IT and HR).

Show all requests for an external organization app.itsm.progressiveCapture.organizationDetails.allowOrgRequestsList

  • The default setting for this is OFF.
  • When this setting is ON, the analyst viewing the Organization Details form, can see the active requests for the organization in the right-hand panel.
  • The requests returned are active ones, and only the requests raised against services that the viewing user supports are displayed.

Visibility of a request’s Questions section

The following settings influence how information from customized forms in Intelligent Capture are made available within the Questions section of a request.

Hide unanswered questions in the Service Manager app app.request.questions.hideUnansweredQuestions

  • The default setting for this is OFF.
  • Fields on a customized form in Intelligent Capture can be set specifying whether they require a value or if a value is optional. If a value is not required, a user can move on without providing a response.
  • When this setting is ON, any unanswered fields from custom forms used in Intelligent Capture will not be displayed in the Questions section of a request.

Hide unanswered questions on the Customer Portal guest.servicemanager.customer.request.questions.hideUnansweredQuestions

  • The default setting for this is OFF.
  • When this setting is ON, unanswered fields in the Questions section of a request are hidden from contacts in the Customer Portal.

Hide unanswered questions on the Employee Portal guest.servicemanager.portal.request.questions.hideUnansweredQuestions

  • The default setting for this is OFF.
  • When this setting is ON, unanswered fields in the Questions section of a request are hidden from users in the Employee Portal.

Hide unused conditional questions app.request.questions.excludeConditionalQuestions

  • The default setting for this is OFF.
  • When designing an Intelligent Capture script, a user may find that some fields on a customized form are displayed only under certain conditions.
  • When this setting is ON, conditional questions that are not displayed to the user are prevented from being stored in the Questions section of a request.

Hide questions that are not visible on forms guest.request.questions.excludeHiddenQuestions

  • The default setting for this is OFF.
  • On a Customized Capture form, each field has an option to make it visible.
  • When this setting is ON, fields on customized forms that are not set to being visible are excluded from the Questions section of a request, when viewed from either the Customer or Employee Portal.
  • When this setting is ON, all questions are still visible on the Questions section when viewed in the Service Manager app.
  • When this setting is ON, all fields are still added to the h_itsm_questions table. This enables hidden questions with default values to still be utilized in a workflowBPM.

Request list settings

com.hornbill.servicemanager.requestList.restrictions.service

  • The default setting for this is ON.
  • When this setting is ON, it is only possible to perform multi-select actions against requests logged against the same service. When selecting requests logged against different services, the multi-select action buttons are hidden.
  • When this setting is OFF, it is possible to perform multi-select actions against requests logged against different services.

com.hornbill.servicemanager.requestList.restrictions.type

  • The default setting for this is ON.

  • When this setting is ON, it is only possible to perform multi-select actions against requests of the same type. When selecting requests of different types, the multi-select action buttons are hidden.

  • When this setting is OFF, it is possible to perform multi-select actions against requests of any types.

    Note

    When the multi-select restrictions are OFF, the supporting-teams logic is disabled on the Assign option on the request list, making it possible to assign requests to teams that are not listed as supporting the services requests are logged against.

webapp.view.ITSM.serviceDesk.requests.list.enableNoTeamAllUsers

  • The default setting for this is OFF.
  • When this setting is ON, it is possible for ANY Service Manager subscriber to see any requests that are not assigned to any team.
  • When this setting is OFF, it is only possible for Service Manager subscribers with the Service Desk Admin role to see any requests that are not assigned to any team.

Raise New Button

The Raise New button can be configured to only show the Raise New option or just the list of request types. This also applies to the Raise New option on the request form.

app.request.raiseNew.hide

  • The default setting is OFF.
  • When set to On the generic Raise New option will be hidden and the user will only have to option to select a specific request type.

app.request.raiseNew.limit

  • Teh default setting is OFF
  • When set to ON only the Raise New option will be available. This removes the ability for a user to select a specific request type.

Request settings

app.request.questions.excludeConditionalQuestions

  • The default setting for this is OFF.
  • When this setting is OFF, conditional Intelligent Capture questions that were not displayed in Intelligent Capture flows will appear in the Questions section on the request forms.
  • When this setting is ON, conditional Intelligent Capture questions that were not displayed in Intelligent Capture flows will not appear in the Questions section on the request forms.

Knowledge Center settings

This feature allows agents and customers to be presented with relevant knowledge when using Intelligent Capture in the user app and the Customer and Employee Portals,respectively.

guest.app.experimental.hornbillKnowledgeCentre

  • The default setting for this is OFF.

  • When this setting is ON, you must also set which interfaces will see the Knowledge Center in Intelligent Capture. This is controlled by the following system settings:

    guest.app.knowledge.customer

    • The default setting for this is OFF.
    • When this setting is ON, the relevant knowledge is shown when a user logs a new request in the Customer Portal.

    guest.app.knowledge.service

    • The default setting for this is OFF.
    • When this setting is ON, the relevant knowledge is shown when a user logs a new request in the Employee portal.

    guest.app.knowledge.user

    • The default setting for this is OFF.
    • When this setting is ON, the relevant knowledge is shown when a user logs a new request in the user app.

Timeline settings

guest.servicemanager.request.timeline.showShortPostTitle

  • The default setting for this is ON.
  • When this setting is ON, the name of the user who posted on the timeline of the request will be displayed when the timeline of the request is viewed in the Customer and Employee Portals.
  • When this setting is OFF, the name of the user who performed the post can still be viewed by hovering over the image of the user on each post.

servicemanager.request.timeline.showShortPostTitle

  • The default setting for this is ON.
  • When this setting is ON, the name of the user who posted on the timeline of the request in the user app will be displayed when the timeline of the request is viewed.
  • When this setting is OFF, the name of the user who performed the post can still be viewed by hovering over the image of the user on each post.

guest.servicemanager.request.timeline.availablePostTypes.editPost

  • This setting determines the type of posts that a user is allowed to edit. Selecting additional post types allows a user to edit their own post in a timeline, provided that the post has not been liked or commented on.
  • The default setting for this is NONE; that is, the option to edit a post is disabled.

Configuration management settings

app.cm.explorer.diagram.expand

These are the entities that can be expanded in the Explorer. The entities with false will have no icon to expand/collapse. If a new entity is added in the future, and this object is not updated with the new entity name, then its value will be set to the default value, which is false (i.e. the user will not be able to expand/collapse the nodes for that entity).

The entities currently shown in the diagram are Asset, Colleagues, Contact, Attachment, Requests, Services.

Default settings:

  • Asset: true
  • Colleagues: false
  • Contact: false
  • Attachment: false
  • Requests: true
  • Services: true
  • default: false

app.cm.explorer.diagram.level.max

  • The maximum level shown in the Explorer. The minimum value is 2 (root plus children).
  • The default is 3.

app.cm.explorer.items.dependencies

  • This setting holds the possible dependencies that can be set between two entities.
  • The possible entities are Asset, Colleagues, Contact, Attachment, Requests, and Services. The property definitions hold all possible lists of values.

To associate a list to two linked entities:

  1. Add a property by following this rule:

    From + entity1 + To + entity2, where entity1 and entity2 can be any value chosen from Asset, Colleagues, Contact, Attachment, Requests, or Services. If the two entities are the same (e.g., two assets), then you may define the list of possible values as AssetFromParentToChild and AssetFromChildToParent.

    This works the same way for other entities. Any missing value will default to the list in defs.default.

    “defs” : {
    “set1” : [“Connected To”, “Depends On”, “Installed On”],
    “set2” : [“Connected To”, “Depends On”, “Installed On”],
    “default” : [“Connected To”, “Depends On”, “Installed On”]
    }
    “FromAssetToRequests” : “set1”,
    “FromRequestsToAsset” : “set2”,
    “FromAssetToServices” : “set2”,
    “AssetFromParentToChild” : “set2”,
    “AssetFromChildToParent” : “set2”
    app.cm.explorer.items.inPolicy
    {{{2}}}
    “Asset” : true,
    “Colleagues” : true,
    “Contact” : true,
    “Attachment” : true,
    “Requests” : true,
    “Services” : true,
    “default” : true

Connections settings

Connections are users and contacts that have been associated with a request. Compared to the main customer of a request, a connection has limited access that only allows them to either view or collaborate on the request. They cannot perform any actions that would progress the workflow.

  • guest.app.requests.notification.emailTemplate.requestConnectionAdded. The email template to be used when sending an email notification to the user or contact, letting them know that they have been added.

    • Default setting: RequestConnectionAddedNotification

    Information

    The RequestConnectionsAddedNotification is an email template that is installed with Service Manager.

  • guest.app.requests.notification.notificationType.connectionsRecipient. Set the default notification type to new connections when they are added to a request. This setting only sets the default value. Users can change their personal notifications settings on their user profile and override this setting.

    • Default: email-only

  • guest.servicemanager.portal.request.canConnectionsViewAttachments. Allow conections to view the attachments against a request. This only applies to attachments that are visible to the customer.

  • guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility.connections’ Default visibility for the request timeline entry that is recorded when adding connections to a request.

    • Default: Customer

Related features

Notification Settings

Service Manager provides the ability to compliment the Hornbill Platform notifications with application specific notifications for analysts. Notification options can be globally controlled and configured in Hornbill administration under Home > Service Manager > Settings, or Service Manager analysts can be given the rights to configure their own notification preferences.

User Defined Notification Settings

By Default global notification settings are applied, and this is detailed below.

If preferred a Hornbill administrator can enable the guest.app.requests.notification.allowUserDefinedNotificationType setting, which will disable the global notification settings and each Service Manager analyst will be able to set their preferences from their Profile > Settings > Notification view.

  • When enabling the user defined notifications, the current global notification settings will be applied to all Service Manager subscribers, and users will need to manage their own.
  • If email notification options are chosen by users, all existing email templates defined for global notification settings will continue to be used.

Email Notification Prerequisites

If you plan on including emails as part of your notifications the following settings need to be configured first.

  • guest.app.requests.notification.emailMailbox

It is necessary to specify the ID of the Hornbill Shared Mailbox (e.g. helpdesk) from which the notifications will originate.

  • guest.app.requests.notification.emailDomain

This application setting must contain the domain from which the notifications will be sent. The domain specified must match an existing outbound mail route that you have configured in Hornbill

  • guest.app.requests.notification.emailPrefix

It is necessary to specify the email prefix to be used when sending application generated email notifications from the instance. Default value is noreply. This works in conjunction with guest.app.requests.notification.emailDomain and will represent the email address from which notifications will be sent.

  • guest.app.requests.notification.emailPrefixDisplayName

The sender’s display name is “noreply” by default. To configure this, update this setting with the desired display name.

Note: Email notifications for users on customer/service portal updates and approval emails are sent using a direct method, they do not use any mailbox. The originating email address for these emails is guest.app.requests.notification.emailPrefix@guest.app.requests.notification.emailDomain meaning the resulting email address must be correct and valid. All other notifications are sent via the mailbox using the one configured on guest.app.requests.notification.emailMailbox.

Notification Types

It is possible to choose different types of notification for each of the functional areas listed below.

  • Email Only

Analysts will receive an email notification

  • Hornbill Only

Analysts will receive a Hornbill notification accessible through the web and native mobile interfaces

  • Both

Analysts will receive both an email and Hornbill notification

  • None

No notifications will be used (This is the default setting)

Notification Settings

Assignment / Reassignment

Use these settings to notify request owners and team members of request assignments

  • Notification Type

  • guest.app.requests.notification.notificationType.assignment

Notifications will be sent to the individual analyst when a request is assigned to them.

  • guest.app.requests.notification.notificationType.assignmentTeam

Notifications will be sent to all members of a team if a request is assigned to their team without an owner

  • Email Template Settings

  • guest.app.requests.notification.emailTemplate.analystAssignment

Use this setting to specify the email template to use when guest.app.requests.notification.notificationType.assignment is set to use email notifications

  • gues t.app.requests.notification.emailTemplate.groupAs signme nt

Use this setting to specify the email template to use when guest.app.requests.notification.notificationType.assignmentTeam is set to use email notifications

Canceled Request

Used these settings to notify request owners and team members of a canceled request

  • guest.app.requests.notification.notificationType.cancel

Notification type for the owner that a canceled request is assigned to

  • guest.app.requests.notification.notificationType.cancelTeam

Notification type for the team that a canceled request is assigned to, when there is no owner assigned

Customer Feedback

Use these settings to notify support staff that the feedback for a request has been submitted by the customer

  • guest.app.requests.notification.notificationType.feedbackSubmitted

Set the notification type that is sent to the owner of the request

  • guest.app.requests.notification.notificationType.feedbackSubmittedTeam

Set the notification type that is sent to the team, if there is no owner.

  • guest.app.requests.notification.emailTemplate.analystFeedbackSubmitted

Use this setting to specify the email template to use when guest.app.requests.notification.notificationType.feedbackSubmitted is set to use email notifications

  • guest.app.requests.notification.emailTemplate.teamFeedbackSubmitted

Use this setting to specify the email template to use when guest.app.requests.notification.notificationType.feedbackSubmittedTeam is set to use email notifications

Email Update

Used these settings to notify the request owner or team members when a request has been updated by an incoming email, either automatically using the Routing Rules, or manually.

  • guest.app.requests.notification.notificationType.emailUpdate

Notifications will be sent to the individual analyst if a request which is assigned to them is updated via email

  • guest.app.requests.notification.notificationType.emailUpdateTeam

Notifications will be sent to all members of a team if a request which is assigned to them is updated via email

Linked Request Resolved / Closed

Notification settings for request owners and team members when their request has been resolved or closed by a linked request

  • Notification Types

  • guest.app.requests.notification.notificationType.analystLinkedRequestResolveAction

Notification type for the owner of a resolved or closed linked request

  • guest.app.requests.notification.notificationType.teamLinkedRequestResolveAction

Notification type for the team that a resolved or closed linked request belongs to

Members

Settings for notifications when using the Members feature on a Request

  • guest.app.requests.notification.notificationType.members

Notifications will be sent to the individual analyst if a new member is added to a request which is assigned to them.

  • guest.app.requests.notification.notificationType.membersTeam

Notifications will be sent to all members of a team if a new member is added to a request which is assigned to them.

  • guest.app.requests.notification.notificationType.membersRecipient

Notifications will be sent to the individual members who are added to a request.

Portal Update

These settings will notify the request owner or team members when a customer updates a request using one of the portals

  • guest.app.requests.notification.notificationType.portalUpdate

Notifications will be sent to the individual analyst if a customer updates a request via the Customer or Service portals.

  • guest.app.requests.notification.notificationType.portalUpdateTeam

Notifications will be sent to all members of a team if a customer updates a request via the Customer or Service portals.

Email Notification Templates

If using the Email Only or Both notification options for any of the functional areas, it is possible to configure the email templates which are sent. Default email templates are provided for each of the following functions:

  • Resolve Linked Request Owner (ResolutionNotification)

  • Close Linked Request Owner (ResolutionNotification)

  • Resolve Linked Request Team’ (ResolutionTeamNotification)

  • Close Linked Request Team (ResolutionTeamNotification)

  • Analyst Email Update (AnalystEmailUpdateNotification)

  • Team Email Update (TeamEmailUpdateNotification)

  • Analyst Request Member Added (AnalystRequestMemberAddedNotification)

  • Team Request Member Added (TeamRequestMemberAddedNotification)

  • Member Added to Request (RequestMemberAddedNotification)

  • It is possible to change the email template which is used for each different notification type by configuring a different email template for each setting.

  • If there is no email template option for a notification setting visible, then the email template is hard coded for example Cancel notifications.

  • It is possible to edit the content of the above email templates if required from the administration console under Home > System > Email > Templates > Service Manager > Requests.

Email Escalation Notifications

In addition to the notification options described above, it is also possible to configure email notifications for escalation actions against Service Level Targets. The configuration for these is covered in the following section: Service Level Escalation Notifications

  • Version {{docApp.book.version}}
  • Node {{docApp.node}} / {{docApp.build}}
In This Document