Release Information > Version 2.1

Functions for automation to save time

Automatic start processing of tickets

Use case:

Unique tickets should no longer have to be classified by an IT employee, but can be processed directly in order to reduce manual activities for these tickets

Implementation:

Option that tickets created from the Self-Service Portal (SSP) are automatically set to the "Processing" ticket status

This relates to the following ticket options:

All service requests of the type "Order" from the SSP web shop

Tickets that are created on the basis of defined ticket templates (also by internal employees)

If there is an approval process for the ticket, this is started automatically

If individual mandatory fields have been defined for the ticket type, these must be filled in as before by the ticket processor in the "New" or "Classification" status

Additional standard categories can be predefined for orders (mandatory field)

Tasks Workflow packages for store articles

Use case:

When a web store item is ordered, certain tasks may be associated with it that should appear automatically in the service request and not have to be created manually afterwards.

Implementation:

Extension of the item management form to include a reference to task workflow packages

If there are several articles in an order, any task workflows included are added to the ticket tasks one after the other

Create a person directly from the inbox

Use case:

If an unknown sender sends an email to the ticket system, it should be easier to create this person directly from the email object in order to be able to create the ticket directly.

Implementation:

Addition of a corresponding action directly in the email form with automatic transfer of the sender information (email address)

Import for persons: new automatic import options

Use case:

Certain attributes for person objects cannot currently be set via the import. Further useful options are to be added so that these do not have to be set manually afterwards.

Implementation:

Extension of the CSV person import and bMS AD person import with the following additional attributes:

VIP (true/false)

Additional e-mail addresses

Preferred contact type (mandatory)

Never requires authorization (true/false)

SSP access granted (true/false; mandatory)

Authentication option

Windows domain (must be imported if authentication option = Windows)

Important: for mandatory fields, the import template MUST be filled for CSV imports (New CSV template)

Message extension

Individual message settings per ticket

Use case:

In addition to the global automatic emails in the ticket process, it should be possible to deactivate these individually for individual tickets. This is helpful for long-running tickets, for example, to avoid unnecessary emails.

Implementation:

Optional display of a ticket tab "Message options" (editing form and entry form)

These offer the possibility to deactivate all standard messages of the ticket, including deactivation of all messages that are automatically sent by the ticket process

Option to restrict automatic messages per ticket type

Use case:

Currently, an automatic message template for tickets can generally only be activated or deactivated. It should be possible to activate this ticket message only for individual ticket types.

Implementation:

Each message template also contains a list of ticket types

The message is only sent for the specified ticket types

If no ticket type is specified, the message is sent for all ticket types

Permissions: Extension of information and more flexible message options

Use case:

Certain approvals have to be sent to top management. There, more specific or differently prepared information is expected in the approval emails.

If several approvers are involved, information on who has already approved is also expected for their own decision-making.

Implementation:

Expansion of the standard messages to include further specific approval process emails:

Each for new, granted and rejected approvals

Possibility of assigning messages per approval model

Display on the message template for which approval models these are used

Extension of the message templates for approvals to include dynamic placeholders for the approvals/rejections already made at the time of the message and by whom they were made

Extension of the approval object to include this information, also for multi-level approval processes

Email option for admins if bMS import jobs fail

Use Case:

Admins can schedule bMS import jobs based on automatic time intervals. If one of these jobs fails, the admin should receive an automatic email so that they do not have to check these jobs regularly in the system.

Implementation:

Add a notification option to the "bMS Integration" admin tile for bMS import jobs

If activated, all users with "Administration Full" authorization receive an automatic system email if a bMS import job fails, with the information from the job

Second standard email for sending passwords

Use case:

If an account password has been changed, this is sent to the user concerned via a standard email template. In order to increase security, a possibility should be created to send the user name, link to the system and password in separate emails.

Implementation:

Add a second identical message template for password changes in the "People" category

An admin now has the option of defining whether 2 emails should be sent and what information is contained in each email

Automatic transfer of the ticket title to manual email messages from the ticket

Use case:

A ticket processor uses the manual message options to send emails to customers or other recipients from the ticket. In addition to the ticket number, the ticket title should also be automatically included in the email subject for each message option so that it does not have to be entered manually.

Implementation:

In addition to the ticket number, the current ticket title is automatically included in each manual message option

Questionnaire extensions

Questionnaires: Option to send the same questionnaire to multiple recipients in succession

Use case:

Certain questionnaires may have to be completed by several recipients in succession or checked again by another recipient, supplemented and, if necessary, answers corrected (e.g. a questionnaire for onboarding must be completed by HR and the specialist department).

Implementation:

In the "Questionnaires" ticket tab, there is the option of completing or sending questionnaires that have already been answered again yourself using buttons

All answers are saved in the list with a time stamp, even if the question has been answered several times

In the "Questionnaires" ticket tab, the "Questionnaire title" columns have been added to the list of answers for better categorization

The CSV export of the responses will be expanded to include additional columns (questionnaire title; ticket no.; timestamp response; creator of the response)

Questionnaires: Use of questionnaires from ticket templates also during ticket processing

Use case:

Currently, questionnaires from a ticket template can only be used when a ticket is created. The template questionnaire should be selectable during the entire processing time of a ticket and be fillable by the ticket processor or the recipients.

Implementation:

The questionnaire from the template is displayed in the "Questionnaires" ticket tab, including the direct fill-in or send option

If a questionnaire is included in the template, the Questionnaires tab will always be displayed, even if no answers from questionnaires are yet included

Questionnaires: Extension of further options for questionnaires

Use case:

The questionnaires are used for a variety of use cases and require more flexibility and options

Implementation:

Expansion of the maximum number of questions from 20 to 30 for the "list" questionnaire type

Introduction of possible mandatory answers for questionnaire type "List"

Copy function for entire questionnaires to quickly produce variants (both questionnaire types)

Extensions Options for ticket owner groups

Default owner for tickets based on locations and org units

Use Case:

Company units have local IT employees who should process tickets depending on the location and/or org unit. Example: A ticket created by a user at a specific location is to be assigned directly to the group responsible for the location.

Implementation:

Addition of definable standard responsible groups for locations and org. units in addition to ticket type and category

Addition of a new admin tile "Standard responsibilities" in which all existing and new responsibility rules can be maintained centrally using a matrix

Introduction of quick selection buttons on the ticket field "Responsible group" in order to be able to manually select the stored standard group per rule (if available) with one click or to always automatically set the last entered group (if ticket has to be assigned back and forth between 2 responsible groups)

Extension of the group list in the master data management with a tree view to provide a better overview of complex group structures

Restriction for ticket forwarding

Use case:

Certain responsible groups for tickets may only forward them to certain other responsible groups. This is to ensure that certain guidelines for the forwarding or escalation of tickets in the organization are adhered to

Implementation:

Introduction of a list on the responsible group in order to be able to explicitly maintain the restrictions for ticket forwarding

If certain groups are maintained in a group here, only these groups can be selected in tickets that are on this responsible group

If no group is maintained in the list, all groups can always be selected (unchanged status as before)

Other enhancements

Hiding the username/PW login option for SSP login mask

Use case:

For customers who do not want to maintain their own passwords for bTS and only use single sign-on via AD integration, the user name/PW option should be completely hidden. This should also prevent misunderstandings among users who, for example, try to enter the Windows password in bTS.

Implementation:

Introduction of a checkbox in the admin tile "AD integration": "Deactivate password login for SSP"

Only possible if "AD-Login" is activated

It is only possible to deactivate this for SSP login so that there is always a possible fallback for normal users if the AD login is not technically available.

SSP: Display options for standard buttons "Create ticket" and "My tickets"

Use case:

The two standard buttons "Create ticket" and "My tickets" in the header area of the SSP are to be given more flexible display options in terms of coloring and display in order to be able to design the SSP more individually at this point.

Implementation:

In the "Self-Service Portal" admin tile, the header area has been redesigned and individual color options for the two standard buttons have been added

Furthermore, the buttons can optionally be hidden if they should not appear