System Configuration

October 8, 2024

Modern systems have many ways to configure their behavior. Some use configuration files edited on the command line, and some use a graphical interface (and save the information to configuration files in the background), yet others use a database. Maintaining changes and auditing can sometimes be an issue, as it is not always clear who made a change. Making bulk changes is not always possible, and rolling back changes a chore.

OTRS uses a comfortable graphical interface to configure the system. All changes to the default system configuration are stored in the database and can be audited (who changed a setting and when, what was the old and what is the new value) and rolled back to a previous state in case of misconfiguration.

Comfortable search allows finding the needed settings quickly and easily.

Use this screen to manage the system configuration settings. OTRS brings about 1750 configuration settings. The system configuration management screen is available in the System Configuration module of the Administration group.

Manage System Configurations

Note

For security reasons, the configuration settings for the database connection cannot be changed in the graphical user interface of the system configuration. These have to be set manually in Kernel/Config.pm.

To modify a system configuration, you need to do several steps. The following example shows you, how to find, modify, deploy and reset the system configuration FirstnameLastnameOrder.

Find the system configuration by entering a search term lastname into to search box.

With the full-text search, all configuration settings can be scanned for one or more keywords. The full-text search not only searches through the names of the configuration settings, but also the descriptions and values. This allows an element to be found easily even if its name is unknown.

System Configuration – Search For Setting
Select the setting from the search results.

System Configuration – Setting Found
Click on the header of the widget to see the options.

System Configuration – Setting Expanded
Hover the mouse over the widget body to see the Edit this setting button.

System Configuration – Setting Hovered
Click on the Edit this setting button to activate the edit mode. In edit mode the widget gets an orange border on the left.

Note

If a setting is currently edited by another administrator, it is not possible to get access to the edit mode for that setting until the other administrator finished their work.

System Configuration – Setting Clicked
Change the value of the setting. Editing can be cancelled by clicking the Cancel button on the right or hitting the Escape key on your keyboard. When editing is cancelled, all changes made during the current editing session are discarded.

System Configuration – Setting Modified
Click on the Save button. If the modification is saved, the widget gets a green border on the left.

System Configuration – Setting Saved
Go back and click on the Deployment button in the left sidebar. You are also notified in the notification bar, that you have undeployed settings.

System Configuration – Setting Changes
Review the changes.
You can click on the ⇄ button in the top right corner to compare the changes side-by-side.

System Configuration – Setting Different

Click on the Deploy selected changes button. If several settings are changed, it is possible to deploy only the selected settings.
Add a deployment comment, that explain for other administrators, what is changed and why. Use full sentence here.

System Configuration – Deploy Setting

Go back and search again the term lastname to find the modified setting. The widget has a gray border on the left to indicate, this setting is modified.

System Configuration – Setting Deployed

To reset the setting, click on the header of the widget to see the options. Then click on the Reset setting button.

System Configuration – Reset Setting

Click on the Confirm button.
Deploy the settings.

Using The Navigation Tree

Each configuration setting is classified by a category and a navigation group. Navigation groups are individual elements in the main navigation tree. By selecting one of these navigation entries, all settings assigned to the selected group will be shown. As long as no extensions are installed, the category selection is automatically hidden, but as soon as a package is installed which brings its own configuration settings (such as ITSM modules or Survey), the category selection will be revealed. Selecting a category makes the main navigation tree show only the navigation groups belonging to the selected category.

To expand an element, click on the arrow next to it. The number between the parentheses indicates how many settings belongs to this element. If an element has no number, this element is only a wrapper category. It doesn’t have settings, it has only sub-categories.

Using the navigation tree results the same as search for a setting. If you would like to see for a setting to which group belongs to, expand it by clicking on the header of the widget.

System Configuration - Setting Expanded — System Configuration – Setting Expanded

For example FirstnameLastnameOrder can be found in Frontend → Base.

Import And Export System Configurations

Click on the Import & Export button in the left sidebar to access the import-export screen.

System Configuration - Import and Export — System Configuration – Import and Export

To export the system configurations:

Click on the Export current configuration button in the Export widget.
Save the Export_Current_System_Configuration.yml file to your local file system.
Rename the file to a more descriptive name.

To import the system configurations:

Click on the Browse… button in the Import widget.
Select a previously exported .yml file.
Click on the Import system configuration button.

Note

This feature is only available to On-Premise customers. If you are a Managed customer, this feature is taken care of by the Customer Solutions Team in OTRS. Please contact us via support@otrs.com or in the OTRS Portal.

Deployment History

Previous revisions can be viewed and restored individually. This makes it easy to reset a setting, reducing errors and downtime. In addition, changes are auditable and revision-proof – the system registers which changes have been made by whom.

To see the deployment history:

Go to the System Configuration screen.
Click on the Deployment button.
Click on the History button.

Every deployment can be further inspected by clicking on View Details link next to it. Details screen can be used to compare the setting with its previous value, before the deployment took place.

It is possible to compare the old and the new settings side-by-side by clicking on the two arrows button.

Additionally, older deployments (every one before current state) can be restored with a simple click. By restoring a deployment, all settings will be reverted to the value they had at the time of the deployment in question.

Finally, deployments can be exported with click on the export button. User will be presented with a download of a YML file that contains changed settings. This YML file can be later restored via Import & Export screen in the system configuration.

Note

If several history entries are displayed in the history, use the filter box to find a particular log entry by just typing the name to filter.

Setting History

Specific setting history can be accessed via History button in the setting widget. This button opens a screen of all values setting had over different deployments. Information like name of the user that made the change and time of change is displayed, along with a useful comparison tool.

To see the setting history:

Go to the System Configuration screen.
Search for a system configuration setting.
Open the setting for editing and click on its header to reveal the buttons.
Click on the History button.

Every historical setting value can be restored by clicking on the Restore button in top right corner of the widget.

Business Object Configuration

The following section contains a description of the business object configuration, including the business object lists, business object detail views, business cards and forms.

Business Object Lists

The business object lists provide a tabular view of items with support for configurable columns, sorting and filtering. These lists can be used in many contexts, including as stand-alone screens, widgets, actions, etc.

The default configuration of business object lists can be defined in several places, depending on the screen or element where they are used.

AgentFrontend::<BusinessObjectListType>::<SlugName>###DefaultConfig

Standalone or static list screens which are usable via their own URL.

An Example of the *Unlocked Tickets* Screen

The following system configuration settings are relevant:

BusinessObjectListType

Type of the business object list to use.

Possible values for the BusinessObjectListType key:

TicketList
KnowledgeBaseArticleList

SlugName

Determines the search engine-friendly URL part via which the screen is available.

Note

Currently only single word search engine-friendly URL parts are supported. Also note that the first character of the search engine-friendly URL part will always be converted to lower case variant, for example:

AgentFrontend::TicketList::Static => /agent/tickets/static
AgentFrontend::TicketList::Unresolved => agent/tickets/unresolved
AgentFrontend::TicketList::Reminders => agent/tickets/reminders
AgentFrontend::KnowledgeBaseArticleList::Added => agent/knowledge-base-articles/added

AgentFrontend::WebNotificationList###DefaultConfig

The default configuration for the Web Notifications list.

An Example of the *Web Notifications* List Screen

Link to the reference of the system configuration:

AgentFrontend::WebNotificationList###DefaultConfig

AgentFrontend::Search###001-Framework

The default configuration for the Search Results list.

An Example of the *Search Results* List Screen

Link to the reference of the system configuration:

AgentFrontend::TicketList::ArticlePreview###DefaultConfig

The default configuration for the Article Preview in the Ticket list.

An Example of the *Article Preview* in the Ticket List Screen

Link to the reference of the system configuration:

AgentFrontend::TicketList::ArticlePreview###DefaultConfig

AgentFrontend::*###DefaultConfig

The default configuration for the inline business object lists. Inline list tables are shown as part of several actions like Merge Ticket, Link Objects or Append to Ticket.

An Example of the *Link Objects* Action in the Ticket Detail View

The following system configuration settings are relevant:

AgentFrontend::*AddressBookList*###DefaultConfig

The default configuration for the Customer User and Customer address book screens. The address books allow contextual adding of customer and customer user records to target form fields.

An Example of the *Customer User Address Book* List Screen

The following system configuration settings are relevant:

Each business object list setting has a Config key which contains its configuration.

See also

The detailed explanation of the possible Config key values can be found in the Business Object List YAML Configuration chapter.

YAML Configuration Basics

Before we delve too deeply into the business object configuration, it is important to explain the YAML syntax which is heavily used for some of the setting values.

YAML (a recursive acronym for YAML Ain’t Markup Language) is a human-readable data-serialization language. It is commonly used for configuration files, but it can describe data structures of arbitrary complexity.

Although YAML supports many of them, only a few data types are used in the context of OTRS configuration:

Scalar

This is the most basic data type; it could be a number, a string, or a boolean expression. Sometimes it is also referred to as a value.

Number: 42
String1: Foo
String2: 'Foo bar'
String3: "Foo bar Xyzzy"
Boolean1: 1
Boolean2: 0

Note

Scalar data type is never used on its own, but it is always part of another higher-level structure.

List

List contains an arbitrary number of items which can be of any data type. Sometimes it is also referred to as an array.

Each item in a list is divided from others by a separator in the form of a minus sign followed by a single space.

List1:
- Item1
- Item2
- Item3

It is recommended that list items are indented via a minus sign followed by a single space. This style is used throughout this guide and default configuration.

Warning

In YAML, the number of spaces is important. The number of spaces used for indentation must always be consistent, otherwise unexpected structures or syntax errors can occur.

Note

To define an empty list, you can use the square bracket syntax:

EmptyList: []

Object

Object is a data type consisting of key/value pairs, separated by the colon punctuation mark. Sometimes it is also referred to as a hash.

Object key is always on the left side of the colon punctuation mark, while the value is always on its right side (or indented below):

Object1:
  Key1: Value1
  Key2: Value2
  Key3: Value3

It is recommended that object key/value pairs are indented with two spaces. This style is used throughout this guide and default configuration.

Warning

In YAML, the number of spaces is important. The number of spaces used for indentation must always be consistent, otherwise unexpected structures or syntax errors can occur.

Note

To define an empty object, you can use the curly brackets syntax:

EmptyObject: {}

To signal that a text uses YAML syntax, it is recommended to add a document header to its first line that consists of three consecutive minus signs, followed by the line break. By doing this consistently, it becomes very easy to identify YAML structures when mixed with other configurations.

With the three basic data types explained above, it is possible to create more complex structures. For example, an array of hashes:

---
Array:
- Key1: A
  Key2: B
  Key3: C
- Key1: 1
  Key2: 2
  Key3: 3
- Key1: I
  Key2: II
  Key3: III

Note

In a list that contains multiple object keys, only the first key must be prefixed with the minus sign followed by a space. Each subsequent key must be prefixed with two spaces.

The following example illustrates the usage of a hash of arrays:

---
Hash:
  Key:
    Subkey1:
    - Item1
    - Item2
    - Item3
    Subkey2:
    - Item4
    - Item5
    - Item6

Note

If the object keys are separated by other structures, it is important to keep them on the same indentation level. Since they are all siblings, they must be prefixed by the same number of spaces.

It is also possible to mix the data types that result in more complex data structures:

---
Key1:
- Subkey1: Value1
- Subkey2: Value2
Key2: Value3
Key3:
  Subkey3:
  - Value4
  - Value5

YAML supports comments in its code, so it is possible to include additional text that will be ignored during parsing. This is useful in case users need to describe certain parts of the structure, perhaps for future reference, or to quickly ignore part of the code without actually removing it.

Comments can be marked with #. Any following text will be ignored.

---
# This is a comment
Key: Value # This is another comment
# Key2: Value 2

In the example above, the last line will be ignored too since it starts with #.

If you actually want to use the pound sign as part of your string of values, simply enclose the complete string in quotes.

---
String: 'Comments start with # character'

When you edit an OTRS system setting with the YAML value type, a suitable text editor will be displayed.

When saving the setting, the YAML structure will be checked for validity. In case of an error, it is possible to change and correct the structure.

It is important to understand that only the syntax of the structure is checked during validation. A deep validation will not occur. It is your responsibility as an administrator to ensure that the configuration you specify is correct.

Warning

The most common errors that occur are related to indentation. You have to ensure that your indentations are consistent, especially the indentations of the different data types. For example, the following two structures are considered different.

---
Object:
   Key:
      Subkey: Value

---
Object:
   Key:
   Subkey: Value

Since the Subkey in the second example is not aligned properly within its parent Key, it is considered to be its sibling part and not a child. In this case the actual value of the Key will be empty.

Business Object List YAML Configuration

A business object list YAML configuration can have many parameters. The following example shows how to construct a business object list in general.

Type: BusinessObject
BusinessObjectType: Ticket
ScreenTitle: <Some Screen Title>
Changeable: 1
FilterPresets:
  "<Displayed Filter Preset Name>":
    <FilterName1>:
      Value: <Value>
    <FilterName2>:
      Value:
      - <Value1>
      - <Value2>
    <FilterName3>:
      Value:
        <Parameter1>: <Value1>
        <Parameter2>: <Value2>
  ...
ActiveFilters:
  <FilterName1>:
    Value: <Value>
  <FilterName2>:
    Value:
    - <Value1>
    - <Value2>
  <FilterName3>:
    Value:
      <Parameter1>: <Value1>
      <Parameter2>: <Value2>
      ...
  ...
AllowGETConfig:
- <ConfigurationName1>
- <ConfigurationName2>
- ...
Columns:
  <ColumnName1>:
    IsVisible: 0|1|2
    IsInlineEditable: 0|1
  ...
DefaultColumnOrder:
- <ColumnName1>
- <ColumnName2>
- ...
HideAvailableFilters:
- <FilterName1>
- <FilterName2>
- ...
ItemsPerPage: 10
Limit: 1000
SortBy:
- Column: <ColumnName>
  Direction: Down|Up
- ...
AvailableDynamicFieldFilters:
- <FilterName1>
- <FilterName2>
- ...

The following YAML keys and values can be used for business object lists.

Type

Defines the type of the setting. This is an internal value which is always set to BusinessObject and must not be changed.

Warning

Changing this value might result in a broken system configuration.

BusinessObjectType

Defines the business object type of the business object list. This is an internal value which is specific for the current list type and must not be changed.

Warning

Changing this value might result in a broken system configuration.

ScreenTitle

Defines the title of the business object list.

Note

In some places, you may notice # translatable comments that are displayed next to the text values. This marker is only used for the internal collection of translatable strings and has no effect in the changed settings. Adding this comment to modified values will not result in the actual text translation.

The visible text in the configuration can be translated into other languages with custom language files. For more information, see the Custom Language File chapter.

Changeable

Defines whether the business object list can be personalized by the user in the front end. If turned off, the view configuration will not be available and also filter presets for the view cannot be saved. The value can be 1 (on) or 0 (off). The assumed default is off when the key is not used in the definition.

FilterPresets

Defines the pre-defined filters used for the business object list. Multiple filters can be defined here. The filter value can be a string, array or a hash. The following YAML snippet shows examples for all types.

FilterPresets:
  Closed:
    StateType:
      Value: Closed
  Locked:
    LockIDs:
      Value:
      - 2
  "Reminder Reached":
    TicketPending_DateTimeRelative:
      Value:
        Format: minute
        Point: 1
        Start: Before

See also

The list of possible filter names can be found in the Filter Names chapter.

ActiveFilters

Defines the filters that are active when displaying the business object list. Multiple filters can be added here; each is defined by the filter name. The filter value can be a string, array or a hash. The following YAML snippet shows examples for both.

ActiveFilters:
  StateType:
    Value: Closed
  TicketClose_DateTimeRelative:
    Value:
      Start: Before
      Point: 1
      Format: minute

See also

The list of possible filter names can be found in the Filter Names chapter.

AllowGETConfig

Defines what parameters can be changed via the URL with the Config URL query parameter:

AllowGETConfig:
- VisibleColumns
- SortBy
- ActiveFilters
- FilterPresets
- ItemsPerPage
- FilterPresetSelected

The list should contain names of other configuration keys for which definition will be allowed when passed via the correct URL query parameter to the view.

See also

For an example and more information, please see the section about Custom URL Support.

Columns

Defines the columns that are available for the business object list in the front end.

IsVisible: Defines whether the column is not visible (0), not visible by default but the agent can make it visible (1) or visible by default (2).
IsInlineEditable: Defines whether the value in the column is inline editable (1) or not (0).

See also

The list of possible column names can be found in the Column Names chapter.

DefaultColumnOrder

Defines the default column order in the business object list.

HideAvailableFilters

Defines the filters which are not available for the agents in the front end, either in the view configuration or in the filter presets.

ItemsPerPage

Defines the number of objects per page that are displayed by default and the number of new objects that are loaded when the agent scrolls down the list. If omitted, it takes the default value of 10. Although there is no upper limit, it is not advisable to set the value greater than 100 for performance reasons.

Limit

Defines the maximum amount of displayed objects in a business object list. Most of the list types in the system are limited to an upper boundary of 10,000 objects for performance reasons.

SortBy

Defines the sorting criteria and the sorting order of the objects in the business object list.

AvailableDynamicFieldFilters

Defines the list of dynamic fields by name which are available as filters.

Business Object Detail Views

The business object detail views can be organized into several families.

The following settings define the default column layout configuration for the detail view screens.

The following system configuration settings are relevant:

The following settings define the default column layout configuration for the business object overview screens.

The following system configuration settings are relevant:

The following settings define the default column layout configuration for the business object create screens.

An Example of the *Create Email Ticket* Screen

The following system configuration settings are relevant:

The following settings define the custom column layout configurations for adding additional widgets to a specific view. By default, these are empty settings. If additional widgets are added to them, they will be merged with the remaining settings for the corresponding view.

The following system configuration settings are relevant:

Each of the above settings has the same key structure:

Type

Type of the business object screen.

Possible values for the Type key:

BusinessObjectCreate
BusinessObjectDetailView
BusinessObjectOverview

BusinessObjectType

Business object type behind the screen.

Possible values for the BusinessObjectType key:

CustomerCompany
CustomerUser
Dashboard
KnowledgeBaseArticle
Statistic
StatisticReport
Ticket

ColumnLayout

The YAML configuration for different column views.

See also

The detailed explanation of the ColumnLayout key can be found in the Business Object Detail View YAML Configuration chapter.

Business Object Detail View YAML Configuration

The YAML structure defines the content for the one, two or three column views. The definition contains the information about which widgets are displayed per default in each view.

ActiveColumnLayout: OneColumn
OneColumn:
  1:
  - Name: <WidgetName1>
  - Name: <WidgetName2>
  ...
TwoColumns:
  1:
  - Name: <WidgetName1>
  - Name: <WidgetName2>
  ...
  2:
  - Name: <WidgetName3>
  - Name: <WidgetName4>
  ...
ThreeColumns:
  1:
  - Name: <WidgetName1>
  - Name: <WidgetName2>
  ...
  2:
  - Name: <WidgetName3>
  - Name: <WidgetName4>
  ...
  3:
  - Name: <WidgetName5>
  - Name: <WidgetName6>
  ...
StripeSidebar:
- Name: StripePeople
...

Note

The sidebar is only available for business objects of type Ticket.

ActiveColumnLayout: Controls which column layout should be loaded by default. Possible values are: OneColumn, TwoColumns or ThreeColumns.

Available widget names for specific column layouts depend on the specific business object screen.

CalendarOverview

Possible widget names for the Calendar Overview screen.

AppointmentsToday
AppointmentsThisWeek
AppointmentsThisMonth

CustomerCompanyCreate

Possible widget names for the Add Customer screen.

CreateProperties

CustomerCompanyDetailView

Possible widget names for the Customer detail view screen.

CustomerInformation
CustomerUserList
EscalatedTickets
OpenTickets
ReminderTickets
TicketList

CustomerUserCreate

Possible widget names for the Add Customer User screen.

CreateProperties

CustomerUserDetailView

Possible widget names for the Customer User detail view screen.

CustomerInformation
EscalatedTickets
OpenTickets
ReminderTickets
TicketList

Dashboard

Possible widget names for the Dashboard screen.

CalendarView
CustomerList
CustomerUserList
DashboardIframe
DashboardImage
DashboardPeople
EscalatedTickets
KnowledgeBaseArticleList
News
OpenTickets
QueueOverview
RecentlyUpdatedKnowledgeBaseArticles
ReminderTickets
TicketList
UnlockedTickets

KnowledgeBaseArticleCreate

Possible widget names for the Add Knowledge Base Article screen.

CreateProperties

KnowledgeBaseArticleDetailView

Possible widget names for the Knowledge Base Article detail view screen.

KBAAttachments
KBAItemField1
KBAItemField2
KBAItemField3
KBAItemField4
KBAItemField5
KBAItemField6
KBALinkedObjects::CalendarAppointment
KBALinkedObjects::KnowledgeBaseArticle
KBALinkedObjects::Ticket
KBAProperties
KBARating
People

StatisticCreateUpdateView

Possible widget names for the Create Statistic and Edit Statistic screens.

CreateUpdateProperties

StatisticReportCreateUpdateView

Possible widget names for the Create Report and Edit Report screens.

CreateUpdateProperties

StatisticReportOverview

Possible widget names for the Statistics and Reports overview screen.

StatisticLists
StatisticMetrics
StatisticReportList
StatisticStatic

TicketCreate::Email

Possible widget names for the Create Email Ticket screen.

CreateProperties
CustomerHistory
CustomerInformation
CustomerUserHistory

TicketCreate::Phone

Possible widget names for the Create Phone Ticket screen.

CreateProperties
CustomerHistory
CustomerInformation
CustomerUserHistory

TicketCreate::SMS

Possible widget names for the Create SMS Ticket screen.

CreateProperties
CustomerHistory
CustomerInformation
CustomerUserHistory

TicketCreate::Process

Possible widget names for the Create Process Ticket screen.

CreatePropertiesProcess
ProcessInformation

TicketDetailView

Possible widget names for the ticket detail view screen.

Attachments
BusinessProcessInformation
CommunicationCompact
CommunicationStream
CustomerInformation
FormDrafts
LinkedObjects::CalendarAppointment
LinkedObjects::KnowledgeBaseArticle
LinkedObjects::Ticket
People
Properties

Widget Type Definitions

Each widget type provides its own definition that will be inherited by any widget that uses it. For example, let’s take a look how this definition looks for one of the dashboard widget types:

An Example of the *Ticket List* Widget Type in the *Dashboard* Screen

The configuration of this widget type is located in the AgentFrontend::Dashboard::WidgetType###TicketList system configuration setting in YAML format.

A widget type definition contains the following general YAML keys:

Type: BusinessObject
BusinessObjectType: Ticket
ActiveFilters: {}
FilterPresets: {}
Columns: {}
Collapsed: 0
Hidden: 0

Type

Defines whether the related widget type handles a business object or other data. BusinessObject is currently the only supported type, but this might be extended by installed packages.

BusinessObjectType

This key defines the type of object the configuration is valid for. Based on this type, the front end and the back end will handle this object differently. New business object types may also be added by installed packages.

ActiveFilters

This key defines the default filters that are active when displaying the business object list. It contains a hash of filters. A single filter also has a hash structure that normally contains a filter value. The value can be a string, array or hash for special filters like dates.

ActiveFilters:
  <FilterName1>:
    Value:
      <Value>
  <FilterName2>:
     Value:
       <Value>

The following example illustrates two active filters which are showing only tickets that were closed recently:

ActiveFilters:
  StateType:
    Value: Closed
  TicketClose_DateTimeRelative:
    Value:
      Start: Before
      Point: 1
      Format: minute

See also

The list of possible filter names can be found in the Filter Names chapter.

FilterPresets

A hash of default filter preset names with a defined set of filters.

FilterPresets:
  "<Filter Preset Name 1>":
     <FilterName1>:
        Value: <Value>
  "<Filter Preset Name 2>":
     <FilterName2>:
        Value: <Value>

The following example illustrates three separate filter presets: locked, unlocked and unread tickets.

FilterPresets:
  Locked:
    LockIDs:
      Value:
      - 2
  Unlocked:
    LockIDs:
      Value:
      - 1
  Unread:
    AgentTicketFlagSeen:
      Value: Unread

See also

The list of possible filter names can be found in the Filter Names chapter.

Widget Definitions

Each widget provides its own definition that will be merged with the configuration of the inherited widget type. For example, let’s take a look at what this definition looks like for one of the widgets in the customer business object detail view:

An Example of the *Reminder Tickets* Widget in the *Customer* Detail View

The configuration of this widget is located in the AgentFrontend::CustomerCompanyDetailView::Widget###ReminderTickets system configuration setting in YAML format.

A widget definition contains the following general YAML keys:

Title: Reminders # Translatable
Active: 1
IsVisible: 1
IsAlwaysPresent: 0
IsDuplicatable: 1
Config: {}

Active: Defines whether the widget is active.
Collapsed: Defines whether the form group is collapsed by default.
Config: This key contains the complete default configuration of a widget. If left empty, the configuration of the widget type is used.
Hidden: Defines whether the widget is hidden.
IsVisible: Defines whether the widget is visible per default.
IsAlwaysPresent: Defines whether the widget can be removed from a view by the user.
IsDuplicatable: Defines whether the widget can be placed in a view multiple times.
Title: Defines the displayed title of a widget in the header section.

Note

In some places, you may notice # translatable comments that are displayed next to the text values. This marker is only used for the internal collection of translatable strings and has no effect in the changed settings. Adding this comment to modified values will not result in the actual text translation.

The visible text in the configuration can be translated into other languages with custom language files. For more information, see the Custom Language File chapter.

If the widget contains a business object list:

Columns

A hash with column names that are displayed in the business object list.

Columns:
  <ColumnName1>:
     IsVisible: <Value>
  <ColumnName2>:
     IsVisible: <Value>

Possible values for the IsVisible key:

0 = not available
1 = available but not visible
2 = available and visible

See also

The list of possible column names can be found in the Column Names chapter.

ArticleDynamicFields

Contains a list of dynamic fields to be displayed in the article preview. The dynamic fields must be added without the prefix DynamicField_.

ArticleDynamicFields:
  - <FieldName1>
  - <FieldName2>
  ...

ArticleViewType

Defines whether the articles should be displayed collapsed or expanded by default.

ArticleViewType: collapsed

DefaultColumnOrder

An array of column names that defines the default column order in the business object list.

DefaultColumnOrder:
- <ColumnName1>
- <ColumnName2>
...

DefaultFilterPresetFields

Defines the default filter preset fields and their values.

DefaultFilterPresetFields:
  <FilterName1>:
    Value: '<Value>'
  <FilterName2>:
    Value: '<Value>'

CountPolling

This determines whether the organizer item queries the current number of its objects in the background and displays them in a speech bubble next to the icon.

CountPolling: ShowNumberFoundItems

Possible values for the CountPolling key:

0 = do not show number
ShowNumberFoundItems = show number of found tickets

Header

This key contains the definition of information fields to be displayed in the header section of the agent business cards.

Header:
  Properties:
  - Name: Avatar
    IsVisible: 1

HideAvailableFilters

This key contains a list of filter names that are not present in the list of available filters in the widget configuration.

HideAvailableFilters:
- <FilterName1>
- <FilterName2>
- <FilterName3>

The following example hides filters for the ticket customer, text search and ticket type:

HideAvailableFilters:
- CustomerID
- Fulltext
- TypeIDs

Identifier

Defines the property that will be used as a full-width card in the Properties widget. The property must be a unique identifier of the business object. If defined this property can be configured separately from other cards.

Identifier:
  Name: TicketNumber
  IsVisible: 0

InitialLimit

Defines the limit of displayed agents in the stripe sidebar in the collapsed state.

ItemsPerPage

A number that defines the number of items per page or load.

Limit

A number that defines the maximum amount of displayed items.

LastUsedFilterPreset

Defines the last used filter preset of a widget. This will be automatically applied when the widget is loaded.

LastUsedFilterPreset: "Reminder Reached"

Properties

The properties are special containers (cards) within a widget that contain detailed information about a specific value of the associated business object. The cards have the option to allow editing of the associated value directly, such as setting a new queue or the owner of a ticket. The properties list in the configuration contains the name and default visibility state of every property.

Properties:
- Name: ArchiveFlag
  IsVisible: 1
- Name: Created
  IsVisible: 1
- Name: CustomerTickets
  IsVisible: 1
- Name: Lock
  IsVisible: 1
  IsInlineEditable: 0
- Name: Watch
  IsVisible: 1
  IsInlineEditable: 0

Possible values for the IsVisible key:

0 = not available
1 = available but not visible
2 = available and visible

Possible values for the IsInlineEditable key:

0 = not editable
1 = editable

ShowPropertyOnEmpty

Defines whether the customer or customer user business card is displayed in the customer information widget when it does not contain a value.

ShowPropertyOnEmpty: 1

Note

This key is supported only by the customer and customer user business cards and cannot be used for regular property cards.

SortBy

Defines the sort order of the business object list. To sort by multiple columns simultaneously, add each sort column as a separate element in the configuration.

SortBy:
- Column: Created
  Direction: Down
- Column: Priority
  Direction: Up

See also

The list of sortable columns per business object type can be found in the Column Names chapter. Look for the ⇅ marker next to the column name.

Note

Only certain business object types support the multi-sorting feature, please see Column Names chapter for more information.

Forms

The configurable forms can be used in many screens, including ticket and article actions. The form configuration will define the fields and properties displayed for each action. Here is the form of Add Note action as an example.

The configuration of this form is located in the Forms###AgentFrontend::Ticket::Action::Note system configuration setting in YAML format.

In general a form can contain a list of fields and form groups. Both are optional and can be added multiple times.

---
- <Field>
- ...
- <FormGroup>
- ...

The field is the basic element of a form. A field can have multiple properties.

- Name: <InternalName>
  Label: <Displayed Label>
  Config:
    <Parameter>:
    - <value>
    - ...
  Default: <default value>
  Description: <some description>
  Disabled: 1
  Hidden: 1
  Hint: <some hint>
  Required: 1
  Props:
    MaxLength: 20

The following keys and values can be used for the fields.

Warning

The keys marked with the * symbol are mandatory. Skipping them might result in broken configuration and/or non-functional features.

If a non-mandatory key is missing from the form field configuration, it will assume the built-in default behavior.

Warning

Most forms and their fields are subject to existing Access Control Lists (ACL). These rules have the final word on which values can be used in the fields and which will overwrite the form configuration.

Name *

Defines the internal name of the field. This key has pre-defined values for each form.

See also

The list of possible field names can be found in the Form Fields chapter.

The dynamic fields can also be added to the form by using the DynamicField_ prefix and the name of the dynamic field. For example, if there is a dynamic field with the name TestDropdown, you need to use DynamicField_TestDropdown in the form configuration.

Label

Defines the label of the field displayed above the input element. If omitted, the default label is displayed for the field specified with Name.

Note

The visible text in the configuration can be translated into other languages with custom language files. For more information, see the Custom Language File chapter.

Config

Defines the values that can be selected in a drop-down list. The values depend on the field specified with Name.

- Name: StateID
  Config:
    StateType:
    - open
    - pending auto
    - pending reminder
    - closed
  Default: 4 # open

Note

The Config key is not applicable for all fields. It is only supported for specific fields. If the key is missing from the default configuration, it is most likely not supported by that field.

Default

Defines the default value for the field. If the form field refers to an ID, the default value will be an ID from the appropriate database table.

In the example above, the state type open has the id=4 in the ticket_state table.

Note

The Default key must refer to a constant value. Substituting it with search terms, regular expressions or similar constructs is currently not supported.

Description

Defines the description of the field. The description is displayed next to the label as a bubble icon and shows a tooltip when the mouse is hovered.

Disabled

Defines whether the field is displayed in a disabled state. A disabled field means that the field is read-only. The field value will, however, be sent by submitting the form.

Hidden

Defines whether the field will be hidden. A hidden field is still part of the form and its value will be sent by submitting the form, but it will not be displayed in the user interface.

Hint

Defines explanation text for the field which is displayed below the input element as help text.

Required: Defines whether the field is mandatory. A mandatory field cannot be empty.
Props: Props are like traits or additional behavior of the front end components, and normally they are used in the source code by the developers, but the configurable form feature now allows modifying their values.

See also

For the complete list of props, see the API documentation of the design system.

The fields can be grouped into form groups. The form groups can contain other form groups or fields. The form groups can be displayed in one, two or three column layouts.

- Label: <Displayed Label>
  Collapsible: 1
  Collapsed: 1
  Fields:
  - <Field>
  - ...
  - <FormGroup>
  - ...
  - ColumnLayout: N # Repeated N-times (2 or 3)
    Fields:
    - <Field>
    - ...
    - <FormGroup>
    - ...

The following keys and values can be used for the form groups.

Warning

The keys marked with the * symbol are mandatory. Skipping them might result in broken configuration and/or non-functional features.

Label *

Defines the label of the form group.

Collapsible

Defines whether the form group is collapsible.

Collapsed

Defines whether the form group is collapsed by default.

Fields *

Lists the fields and form groups that belong to this form group. There is no limitation on how many fields can be added or how many form groups can be nested.

If the form group has no fields and acts only as placeholder, then this key has to be defined as an empty list.

- Label: Placeholder Form Group
  Fields: []

ColumnLayout

Defines the grid in the form component. The fields are displayed in one column layout by default. This key can be used only for the two or three column layouts. The width of the columns are the same, 50%-50% for two column layout and 33%-33%-33% for three column layout.

- Label: Two Column Example
  - ColumnLayout: 2
    Fields:
    - Name: IsVisibleForCustomer
  - ColumnLayout: 2
    Fields:
    - Name: MarkAsImportant

Business Cards

Business cards are used throughout the system to display additional information about agent users.

An Example of the Ticket *Owner* Business Card

The configuration of this business card is located in the AgentFrontend::BusinessCard::User system configuration setting in YAML format.

AdditionalProperties

This key is used to show additional user fields in the agent business card. Each field is referenced by its Name key. It is possible to customize its DisplayName and control visibility via IsVisible flag (1 shows it, 0 hides it).

Contact

This key defines contact options in agent business cards. Each property item is referencing a user field with some contact information via the Name key (i.e. UserEmail), an icon to show the user (regular weight only!) and can be made visible via the IsVisible: 1 key. By default, clicking on these contact icons will copy the value of the user field to the clipboard.

Alternatively, the Link key can be specified to show a URL instead. Each Link key supports the TemplateToolkit syntax for replacements, and will receive all of the field values of the user via the Data variable.

Chat

This key adds an icon to call the chat function directly from a business card.

Header

This key defines the information shown in the header of a business card. Each field is referenced by its Name key. It is only possible to control the visibility via IsVisible flag (1 shows it; 0 hides it).

Business Object Reference

This chapter lists all possible values for specific business object configurations. The values can be different in each setting.

Column Names

The columns can be referenced by their name. This section lists the possible column names for specific business object types.

Note

The columns marked with the ⇅ symbol are sortable. The default limit for the multi-sorting feature is a maximum of three columns at a time, unless explicitly mentioned differently.

ChatRequest

Possible column names:

Action
Channel ⇅
CreateTime ⇅
Description
RequesterName ⇅
RequesterType ⇅
Type

Note

This business object type does not support the multi-sorting feature. Sorting is supported only by a single column at a time.

CustomerCompany

Possible column names depend on the available fields in the CustomerCompany###Map configuration array. For the default database back end, these include:

CustomerCompanyCity ⇅
CustomerCompanyComment ⇅
CustomerCompanyCountry ⇅
CustomerCompanyName ⇅
CustomerCompanyStreet ⇅
CustomerCompanyURL ⇅
CustomerCompanyZIP ⇅
CustomerID ⇅
ValidID ⇅

Additional column names which are always available:

ClosedTickets
Edit
OpenTickets

CustomerUser

Possible column names depend on the available fields in the CustomerUser###Map and the CustomerCompany###Map configuration arrays. For the default database back ends, these include:

CustomerCompanyCity ⇅
CustomerCompanyComment ⇅
CustomerCompanyCountry ⇅
CustomerCompanyName ⇅
CustomerCompanyStreet ⇅
CustomerCompanyURL ⇅
CustomerCompanyValidID ⇅
CustomerCompanyZIP ⇅
CustomerID ⇅
UserCity ⇅
UserComment ⇅
UserCountry ⇅
UserCustomerID ⇅
UserEmail ⇅
UserFax ⇅
UserFirstname ⇅
UserLastname ⇅
UserLogin ⇅
UserMobile ⇅
UserPassword ⇅
UserPhone ⇅
UserStreet ⇅
UserTitle ⇅
UserZip ⇅
ValidID ⇅

Additional column names which are always available:

Chat
ClosedTickets
CreateTicket
Edit
OpenTickets
SwitchToCustomer

FormDraft

Possible column names:

Delete
Saved
Title
Type

KnowledgeBaseArticle

Possible column names:

Approved
Category ⇅
Changed ⇅
ChangedBy
ContentType
Created ⇅
CreatedBy
Helpful
Language ⇅
NotHelpful
Number ⇅
State ⇅
Title ⇅
Valid ⇅

KnowledgeBaseArticleAttachment

Possible column names:

ContentType ⇅
CreateTime ⇅
Download
Filename ⇅
Filesize ⇅
Preview

Note

This business object type does not support the multi-sorting feature. Sorting is supported only by a single column at a time.

Search

Possible column names:

Result
Source
Type

Statistic

Possible column names:

Changed ⇅
Created ⇅
ObjectName ⇅
ObjectType ⇅
StatNumber ⇅
StatType ⇅
Title ⇅
Valid

Note

This business object type does not support the multi-sorting feature. Sorting is supported only by a single column at a time.

StatisticReport

Possible column names:

ChangeTime ⇅
CreateTime ⇅
CronDefinition
Description
Language
Name ⇅
Valid ⇅

Note

This business object type does not support the multi-sorting feature. Sorting is supported only by a single column at a time.

Ticket

Possible column names:

Age ⇅
ArticleTree
Changed ⇅
Created ⇅
CreatedBy
CustomerCompanyName
CustomerID ⇅
CustomerName
CustomerUserID
EscalationResponseTime ⇅
EscalationSolutionTime ⇅
EscalationTime ⇅
EscalationUpdateTime ⇅
Lock ⇅
Owner ⇅
PendingTime ⇅
Priority ⇅
Queue ⇅
Responsible ⇅
Sender
Service ⇅
SLA ⇅
State ⇅
Subject
TicketNumber ⇅
Title ⇅
Type ⇅
Watch

TicketArticle

Possible column names:

ArticleNumber ⇅
ArticleProperties
Attachment
Channel ⇅
CreateTime ⇅
Direction
Sender
Status
Subject

Note

This business object type does not support the multi-sorting feature. Sorting is supported only by a single column at a time.

TicketAttachment

Possible column names:

ContentType ⇅
CreateTime ⇅
Direction ⇅
Download
Filename ⇅
Filesize ⇅
Preview

Note

This business object type does not support the multi-sorting feature. Sorting is supported only by a single column at a time.

WebNotification

Possible column names:

CreateTime ⇅
Name ⇅
ObjectReference ⇅
ObjectType ⇅
Subject ⇅

Filter Names

Filters can be referenced by their names. This section lists the possible filter names for specific business object types. Each filter has a value type displayed next to it that can be used to quickly jump to the reference.

See also

The list of possible filter value types can be found in the Filter Value Types chapter.

Note

The filters marked with the × symbol support array values for multiple matches.

ChatRequest

The following filter names and values can be used for the Chat Request business object lists.

ChannelIDs: array ×

Defines the IDs of the chat channels.

Create_DateTimeRange: absolute date

Defines the absolute range of the chat request creation time.

Create_DateTimeRelative: relative date

Defines the relative range of the chat request creation time.

RequesterType: array ×

Defines the type of the user that initiated the chat request.

User: The user is an agent.
Customer: The user is a customer user.
Public: The user is anonymous (public user).

Type: array ×

Defines the type of the chat request.

Invitation: The invitation to a chat initiated by another agent user.
Request: A chat request initiated by a customer user or a public user.

CustomerCompany

The following filter names and values can be used for the Customer business object lists.

CustomerCompanyCity: string

Defines the text when searching for the customer city. Wildcard * can be used. The search is case insensitive.

CustomerCompanyComment: string

Defines the text when searching for the customer comment. Wildcard * can be used. The search is case insensitive.

CustomerCompanyCountry: string

Defines the text when searching for the customer country. Wildcard * can be used. The search is case insensitive.

CustomerCompanyName: string

Defines the text when searching for the customer name. Wildcard * can be used. The search is case insensitive.

CustomerCompanyStreet: string

Defines the text when searching for the customer street. Wildcard * can be used. The search is case insensitive.

CustomerCompanyURL: string

Defines the text when searching for the customer URL. Wildcard * can be used. The search is case insensitive.

CustomerCompanyZIP: string

Defines the text when searching for the customer postcode. Wildcard * can be used. The search is case insensitive.

CustomerID: string

Defines the text when searching for the customer ID. Wildcard * can be used. The search is case insensitive.

ValidID: array ×

Defines the IDs of the customer validity. By default, these include:

1 = valid
2 = invalid
3 = invalid-temporarily

CustomerUser

The following filter names and values can be used for the Customer User business object lists.

CustomerCompany_CustomerCompanyCity: string

Defines the text when searching for the customer city. Wildcard * can be used. The search is case insensitive.

CustomerCompany_CustomerCompanyComment: string

Defines the text when searching for the customer comment. Wildcard * can be used. The search is case insensitive.

CustomerCompany_CustomerCompanyCountry: string

Defines the text when searching for the customer country. Wildcard * can be used. The search is case insensitive.

CustomerCompany_CustomerCompanyName: string

Defines the text when searching for the customer name. Wildcard * can be used. The search is case insensitive.

CustomerCompany_CustomerCompanyStreet: string

Defines the text when searching for the customer street. Wildcard * can be used. The search is case insensitive.

CustomerCompany_CustomerCompanyURL: string

Defines the text when searching for the customer URL. Wildcard * can be used. The search is case insensitive.

CustomerCompany_CustomerCompanyZIP: string

Defines the text when searching for the customer postcode. Wildcard * can be used. The search is case insensitive.

CustomerCompany_ValidID: array ×

Defines the IDs of the customer validity. By default, these include:

1 = valid
2 = invalid
3 = invalid-temporarily

CustomerID: string

Defines the text when searching for the related customer ID. Wildcard * can be used. The search is case insensitive.

UserCity: string

Defines the text when searching for the customer user city. Wildcard * can be used. The search is case insensitive.

UserComment: string

Defines the text when searching for the customer user comment. Wildcard * can be used. The search is case insensitive.

UserCountry: string

Defines the text when searching for the customer user country. Wildcard * can be used. The search is case insensitive.

UserCustomerID: string

Defines the text when searching for the customer user ID. Wildcard * can be used. The search is case insensitive.

UserEmail: string

Defines the text when searching for the customer user email address. Wildcard * can be used. The search is case insensitive.

UserFax: string

Defines the text when searching for the customer user fax number. Wildcard * can be used. The search is case insensitive.

UserFirstname: string

Defines the text when searching for the customer user first name. Wildcard * can be used. The search is case insensitive.

UserLastname: string

Defines the text when searching for the customer user last name. Wildcard * can be used. The search is case insensitive.

UserLogin: string

Defines the text when searching for the customer user login name (username). Wildcard * can be used. The search is case insensitive.

UserMobile: string

Defines the text when searching for the customer user mobile number. Wildcard * can be used. The search is case insensitive.

UserPhone: string

Defines the text when searching for the customer user phone number. Wildcard * can be used. The search is case insensitive.

UserStreet: string

Defines the text when searching for the customer user street. Wildcard * can be used. The search is case insensitive.

UserTitle: string

Defines the text when searching for the customer user title. Wildcard * can be used. The search is case insensitive.

UserZip: string

Defines the text when searching for the customer user postcode. Wildcard * can be used. The search is case insensitive.

ValidID: array ×

Defines the IDs of the customer user validity. By default, these include:

1 = valid
2 = invalid
3 = invalid-temporarily

KnowledgeBaseArticle

The following filter names and values can be used for the Knowledge Base Article business object lists.

Approved: boolean

Defines whether the article has been approved.

CategoryIDs: array ×

Defines the IDs of the article categories.

CreatedUserIDs: array ×

Defines the IDs of the agents who created the article.

ItemChange_DateTimeRange: absolute date

Defines the absolute range of the article change time.

ItemChange_DateTimeRelative: relative date

Defines the relative range of the article change time.

ItemCreate_DateTimeRange: absolute date

Defines the absolute range of the article create time.

ItemCreate_DateTimeRelative: relative date

Defines the relative range of the article create time.

Keyword: string

Defines the text when searching for the article keyword. Wildcard * can be used. The search is case insensitive.

LanguageIDs: array ×

Defines the IDs of the article language. By default, these include:

en
de

LastChangedUserIDs: array ×

Defines the IDs of the agents who changed the article last.

Number: string

Defines the text when searching for the article number. Wildcard * can be used.

Rate: comparison

Compares the article rating in percentage against the supplied value.

StateIDs: array ×

Defines the IDs of the article state. By default, these include:

1 = internal (agent)
2 = external (customer)
3 = public (all)

Title: string

Defines the text when searching for the article title. Wildcard * can be used. The search is case insensitive.

ValidIDs: array ×

Defines the IDs of the article validity. By default, these include:

1 = valid
2 = invalid
3 = invalid-temporarily

Votes: comparison

Compares the number of votes for the article against the supplied value.

What: string

Defines the text when searching through the article full text. Wildcard * can be used. The search is case insensitive.

KnowledgeBaseArticleAttachment

The following filter names and values can be used for the Knowledge Base Article Attachment business object lists.

Create_DateTimeRange: absolute date: Defines the absolute range of the attachment create time.
Create_DateTimeRelative: relative date: Defines the relative range of the attachment create time.
Filename: string: Defines the text when searching for the attachment filename. Wildcard * and regular expressions can be used. The search is case insensitive.
Type: string: Defines the text when searching for the attachment MIME type. Wildcard * and regular expressions can be used. The search is case insensitive.

Search

The following filter names and values can be used for the Search business object lists.

Appointment Calendar: string

Defines the calendar in which to search for the appointment. Please set it to a string value formatted as:

CalendarID#: Where # is the ID of the calendar, i.e. CalendarID1.

Warning

This filter is applicable only when the filter DocumentType is defined and set to the value Appointment. Otherwise, it will be ignored.

Appointment Schedule: string

Defines the type of the appointment.

AllDay: The appointment is an all day appointment (i.e. it does not have the time component).
TimeFrame: The appointment is a time frame appointment (i.e. it has the time component).

Warning

This filter is applicable only when the filter DocumentType is defined and set to the value Appointment. Otherwise, it will be ignored.

DocumentType: string

Defines the type of document to be searched. By default, these include:

Appointment = Calendar Appointments
FAQ = Knowledge Base Articles
Ticket = Tickets

FAQ FAQ Categories: string

Defines the knowledge base article category for which you are searching. Please set it to a string value formatted as:

CategoryID#: Where # is the ID of the category, i.e. CategoryID1.

Warning

This filter is applicable only when the filter DocumentType is defined and set to the value FAQ. Otherwise, it will be ignored.

FAQ FAQ Languages: string

Defines the knowledge base article language for which you are searching. Please set it to a string value formatted as:

LanguageID#: Where # is the ID of the language, i.e. LanguageID1.

Warning

This filter is applicable only when the filter DocumentType is defined and set to the value FAQ. Otherwise, it will be ignored.

FAQ Has attachments: string

Defines the presence of knowledge base article attachments.

HasAttachments: The article has at least one attachment.

Warning

This filter is applicable only when the filter DocumentType is defined and set to the value FAQ. Otherwise, it will be ignored.

FAQ State: string

Defines the knowledge base article state for which you are searching. Please set it to a string value formatted as:

StateID#: Where # is the ID of the state, i.e. StateID1.

Warning

This filter is applicable only when the filter DocumentType is defined and set to the value FAQ. Otherwise, it will be ignored.

Ticket Has attachments: string

Defines the presence of the ticket article attachments.

HasAttachments: The ticket article has at least one attachment.

Warning

This filter is applicable only when the filter DocumentType is defined and set to the value Ticket. Otherwise, it will be ignored.

Ticket Owner: string

Defines the ID of the agent who is the ticket owner. Please set it to a string value formatted as:

OwnerID#: Where # is the ID of the agent, i.e. OwnerID1.

Warning

This filter is applicable only when the filter DocumentType is defined and set to the value Ticket. Otherwise, it will be ignored.

Ticket Priority: string

Defines the ID of the ticket priority. Please set it to a string value formatted as:

PriorityID#: Where # is the ID of the priority, i.e. PriorityID1.

Warning

This filter is applicable only when the filter DocumentType is defined and set to the value Ticket. Otherwise, it will be ignored.

Ticket Queue: string

Defines the ID of the ticket queue. Please set it to a string value formatted as:

QueueID#: Where # is the ID of the queue, i.e. QueueID1.

Warning

This filter is applicable only when the filter DocumentType is defined and set to the value Ticket. Otherwise, it will be ignored.

Ticket Responsible: string

Defines the ID of the agent who is the ticket responsible. Please set it to a string value formatted as:

ResponsibleID#: Where # is the ID of the agent, i.e. ResponsibleID1.

Warning

This filter is applicable only when the filter DocumentType is defined and set to the value Ticket. Otherwise, it will be ignored.

Ticket Sender type: string

Defines the sender of the ticket articles.

SenderTypeAgent: The sender of the ticket article is an agent user.
SenderTypeCustomer: The sender of the ticket article is a customer user.
SenderTypeSystem: The sender of the ticket article is a system user.

Warning

This filter is applicable only when the filter DocumentType is defined and set to the value Ticket. Otherwise, it will be ignored.

Ticket Service Level Agreement (SLA): string

Defines the ID of the ticket SLA. Please set it to a string value formatted as:

SLAID#: Where # is the ID of the SLA, i.e. SLAID1.

Warning

This filter is applicable only when the filter DocumentType is defined and set to the value Ticket. Otherwise, it will be ignored.

Ticket Service: string

Defines the ID of the ticket service. Please set it to a string value formatted as:

ServiceID#: Where # is the ID of the service, i.e. ServiceID1.

Warning

This filter is applicable only when the filter DocumentType is defined and set to the value Ticket. Otherwise, it will be ignored.

Ticket State: string

Defines the ID of the ticket state. Please set it to a string value formatted as:

StateID#: Where # is the ID of the state, i.e. StateID1.

Warning

This filter is applicable only when the filter DocumentType is defined and set to the value Ticket. Otherwise, it will be ignored.

Ticket Visible to customer: string

Defines whether the ticket articles are visible to the customer user.

IsVisibleForCustomer: Ticket article is visible to the customer user.

Warning

This filter is applicable only when the filter DocumentType is defined and set to the value Ticket. Otherwise, it will be ignored.

Statistic

The following filter names and values can be used for the Statistic business object lists.

StatNumber: string

Defines the text when searching for the statistic number. Wildcard * can be used.

StatType: array ×

Defines the statistic type for which you are searching.

static: The statistic is of the static type.
dynamic: The statistic is of the dynamic type.

Title: string

Defines the text when searching for the statistic name. Wildcard * can be used. The search is case insensitive.

ObjectName: array ×

Defines the statistic object name to be searched. By default, these include:

Ticketlist
TicketAccountedTime
TicketAccumulation
TicketSolutionResponseTime
FAQAccess
StateAction

ObjectType: array ×

Defines the statistic object type to be searched.

DynamicList: The object type is a list.
DynamicMatrix: The object type is a matrix.
Static: The object type is static.

Valid: array ×

Defines the IDs of the statistic validity. By default, these include:

1 = valid
0 = invalid

StatisticReport

The following filter names and values can be used for the Report business object lists.

Name: string

Defines the text when searching for the report name. Wildcard * can be used. The search is case insensitive.

Description: string

Defines the text when searching for the report description. Wildcard * can be used. The search is case insensitive.

LanguageID: string

Defines the report language code, i.e. de.

ValidID: array ×

Defines the IDs of the report validity. By default, these include:

1 = valid
2 = invalid
3 = invalid-temporarily

Ticket

The following filter names and values can be used for the Ticket business object lists.

AgentCreator: boolean

Defines whether the ticket was created by the current agent.

AgentInvolved: boolean

Defines whether the current agent is involved in the ticket.

AgentOwner: boolean

Defines whether the current agent is the ticket owner while the ticket is locked.

AgentQueues: boolean

Defines whether the ticket is in one of the subscribed queues of the current agent. Agents can subscribe to queues via their My Queues personal preference.

AgentResponsible: boolean

Defines whether the current agent is the ticket responsible.

AgentServices: boolean

Defines whether the ticket has one of the subscribed services of the current agent. Agents can subscribe to services via their My Services personal preference.

AgentTicketFlagSeen: string

Defines whether the current agent has read the ticket.

Unread: All articles are unread by the current agent.
Read: All articles are read by the current agent.

AgentWatcher: boolean

Defines whether the current agent is watching the ticket.

ArticleCreate_DateTimeRange: absolute date

Defines the absolute range of the ticket article creation time.

ArticleCreate_DateTimeRelative: relative date

Defines the relative range of the ticket article creation time.

Chat_ChatterName: string

Defines the text when searching for the chat article participants. Wildcard * can be used. The search is case insensitive.

Chat_MessageText: string

Defines the text when searching for the chat article message. Wildcard * can be used. The search is case insensitive.

CreatedQueueIDs: array ×

Defines the IDs of the queues where the ticket was originally created.

CreatedUserIDs: array ×

Defines the IDs of the agents who created the ticket.

CustomerID: string

Defines the text when searching for the ticket customer ID field. Use this filter for a complex search. Wildcard * can be used. The search is case insensitive.

CustomerIDRaw: string

Defines the text when searching for the ticket customer ID field. Use this filter for an exact match. The search is case insensitive.

CustomerUserID: string

Defines whether the ticket is accessible to a specific customer user in the external interface. Supports only exact match. The search is case insensitive.

CustomerUserLogin: string

Defines the text when searching for the ticket customer user ID field. Use this filter for the complex search. Wildcard * can be used. The search is case insensitive.

CustomerUserLoginRaw: string

Defines the text when searching for the ticket customer user ID field. Use this filter for an exact match. The search is case insensitive.

Fulltext: string

Defines the text when searching for the ticket article full text. Wildcard * can be used. The search is case insensitive.

LockIDs: array ×

Defines the IDs of the ticket lock types. By default, these include:

1 = unlock
2 = lock
3 = tmp_lock

MIMEBase_AttachmentName: string

Defines the text when searching for the article attachment names. Wildcard * can be used. The search is case insensitive.

MIMEBase_Bcc: string

Defines the text when searching for the article blind carbon copy field. Wildcard * can be used. The search is case insensitive.

MIMEBase_Body: string

Defines the text when searching for the article body. Wildcard * can be used. The search is case insensitive.

MIMEBase_Cc: string

Defines the text when searching for the article carbon copy field. Wildcard * can be used. The search is case insensitive.

MIMEBase_From: string

Defines the text when searching for the article sender field. Wildcard * can be used. The search is case insensitive.

MIMEBase_Subject: string

Defines the text when searching for the article subject field. Wildcard * can be used. The search is case insensitive.

MIMEBase_To: string

Defines the text when searching for the article recipient field. Wildcard * can be used. The search is case insensitive.

OwnerIDs: array ×

Defines the IDs of the agents who are the ticket owners.

PriorityIDs: array ×

Defines the IDs of the ticket priorities.

QueueIDs: array ×

Defines the IDs of the ticket queues.

ResponsibleIDs: array ×

Defines the IDs of the agents who are the ticket responsibles.

SearchInArchive: string

Defines how the search behaves related to the ticket archive status.

ArchivedTickets: Search in archived tickets only.
NotArchivedTickets: Search in unarchived tickets only.
AllTickets: Search in all tickets.

ServiceIDs: array ×

Defines the IDs of the ticket services.

SLAIDs: array ×

Defines the IDs of the ticket SLAs.

SMS_PhoneNumbers: string

Defines the text when searching for the SMS article recipient phone numbers. Wildcard * can be used. The search is case insensitive.

SMS_Text: string

Defines the text when searching for the SMS article body. Wildcard * can be used. The search is case insensitive.

SMS_TransactionNumbers: string

Defines the text when searching for the SMS article transaction numbers. Wildcard * can be used. The search is case insensitive.

StateIDs: array ×

Defines the IDs of the ticket states.

StateType: string

Defines the ticket state category.

Open: Search in open tickets only.
Closed: Search in closed tickets only.

Warning

Despite its name, this filter does not apply to the actual ticket state types. Open and Closed are not valid state types. They are group constructs included for compatibility reasons. If a ticket is in a state which has any of the state types defined in the Ticket::ViewableStateType setting, it will be considered as open. Otherwise, it is considered as closed.

StateTypeIDs: array ×

Defines the IDs of the ticket state types.

TicketChange_DateTimeRange: absolute date

Defines the absolute range of the ticket change time.

TicketChange_DateTimeRelative: relative date

Defines the relative range of the ticket change time.

TicketClose_DateTimeRange: absolute date

Defines the absolute range of the ticket close time.

TicketClose_DateTimeRelative: relative date

Defines the relative range of the ticket close time.

TicketCreate_DateTimeRange: absolute date

Defines the absolute range of the ticket create time.

TicketCreate_DateTimeRelative: relative date

Defines the relative range of the ticket create time.

TicketEscalation_DateTimeRange: absolute date

Defines the absolute range of the ticket escalation time.

TicketEscalation_DateTimeRelative: relative date

Defines the relative range of the ticket escalation time.

TicketLastChange_DateTimeRange: absolute date

Defines the absolute range of the ticket last change time.

TicketLastChange_DateTimeRelative: relative date

Defines the relative range of the ticket last change time.

TicketNumber: string

Defines the text when searching for the ticket number. Wildcard * can be used.

TicketPending_DateTimeRange: absolute date

Defines the absolute range of the ticket pending time.

TicketPending_DateTimeRelative: relative date

Defines the relative range of the ticket pending time.

Title: string

Defines the text when searching for the ticket title. Wildcard * can be used. The search is case insensitive.

TypeIDs: array ×

Defines the text when searching for the ticket type.

WatchUserIDs: array ×

Defines the IDs of the agents who are watching the ticket.

TicketArticle

The following filter names and values can be used for the Ticket Article business object lists.

CommunicationChannelID: array

IsVisibleForCustomer: string

SenderTypeID: array

TicketAttachment

The following filter names and values can be used for the Ticket Attachment business object lists.

Article: string

Create_DateTimeRange: absolute date

Create_DateTimeRelative: relative date

Direction: array ×

Filename: string

Type: string

WebNotification

The following filter names and values can be used for the Web Notification business object lists.

Name: array ×

Subject: string

ObjectTypes: array ×

Seen: array ×

ObjectReferences: array ×

Filter Value Types

Every filter supports exactly one kind of a value type. Depending on this type, the following structures should be used to define it in the YAML configuration.

Boolean

A simple value that is considered either true or false.

<FilterName1>:
  Value: 1
<FilterName2>:
  Value: 0

1: The filter is active (turned on).
0: The filter is inactive (turned off).

String

A text value, normally used when searching. Check specific filters for more details.

<FilterName1>:
  Value: simple
<FilterName2>:
  Value: 'String with spaces or special characters like @$#!+*'

Array

An array value normally used to search for multiple values at the same time.

<FilterName1>:
  Value:
  - 1
  - 2
  - 3
<FilterName2>:
  Value:
  - 4
  - 5

Absolute date

The time range value between two absolute dates.

<FilterName1>:
  Value:
    Start: '2020-01-01 00:00:00'
    End: '2020-02-01 00:00:00'
<FilterName2>:
  Value:
    Start: '2020-02-01 00:00:00'
    End: '2020-03-01 00:00:00'

Start: Absolute timestamp in ISO format for the start of the range (i.e. 2020-01-01 00:00:00). The value must be supplied in the current system time zone (configurable via the OTRSTimeZone system setting).
End: Absolute timestamp in ISO format for the end of the range (i.e. 2020-02-01 00:00:00). The value must be supplied in the current system time zone (configurable via the OTRSTimeZone system setting).

Relative date

The time range value relative to the current time.

<FilterName1>:
  Value:
    Start: Last
    Point: 1
    Format: month
<FilterName2>:
  Value:
    Start: Before
    Point: 3
    Format: day

Start

The type of the relative range.

Possible values for the Start key:

Last = within the last…
Before = more than … ago

Point

Integer value of the time unit (i.e. 3).

Format

Time unit of the relative range.

Possible values for the Format key:

minute
hour
day
week
month
year

Comparison

The comparison with the supplied value.

<FilterName1>:
  Value:
    Type: Equals
    Value: 25
<FilterName2>:
  Value:
    Start: GreaterThan
    Value: 50

Type

The type of the comparison.

Possible values for the Type key:

Equals = equals …
GreaterThan = greater than …
GreaterThanEquals = greater than or equals …
SmallerThan = smaller than …
SmallerThanEquals = smaller than or equals …

Value

Integer value to compare against (i.e. 25).

Form Fields

The form fields can be defined via their Name key. This section lists the values of the Name key for the specific settings.

See also

Form fields can be made mandatory by setting their Required key to 1.

Possible field names for ticket actions:

Forms###AgentFrontend::Ticket::Action::Close

Configurable form for the Close Ticket action.

Link to the reference of the system configuration:

Forms###AgentFrontend::Ticket::Action::Close

Possible values for the Name key of the form field:

AccountedTime
AddMessage
Attachments
Body
CustomerID
CustomerUserID
DynamicField
HistoryComment
HistoryType
InformAgent
InvolvedAgent
IsVisibleForCustomer
MarkAsImportant
Messages
OwnerID
PriorityID
QueueID
RelevantKnowledge
ResponsibleID
SenderType
ServiceID
SLAID
StandardTemplateID
StateID
Subject
Title
TypeID

Forms###AgentFrontend::Ticket::Action::Customer

Configurable form for the Change Customer action.

Link to the reference of the system configuration:

Forms###AgentFrontend::Ticket::Action::Customer

Possible values for the Name key of the form field:

CustomerUserID
CustomerID

Forms###AgentFrontend::Ticket::Action::EmailOutbound

Configurable form for the Send Email Outbound action.

Link to the reference of the system configuration:

Forms###AgentFrontend::Ticket::Action::EmailOutbound

Possible values for the Name key of the form field:

AccountedTime
Attachments
Bcc
Body
Cc
CustomerID
CustomerUserID
DynamicField
EmailSecurity
From
HistoryComment
HistoryType
InformAgent
InvolvedAgent
IsVisibleForCustomer
MarkAsImportant
Messages
OwnerID
PriorityID
QueueID
RelevantKnowledge
ResponsibleID
SenderType
ServiceID
Signature
SLAID
StandardTemplateID
StateID
Subject
Title
To
TypeID

Forms###AgentFrontend::Ticket::Action::FreeText

Configurable form for the Change Free Fields action.

Link to the reference of the system configuration:

Forms###AgentFrontend::Ticket::Action::FreeText

Possible values for the Name key of the form field:

AccountedTime
AddMessage
Attachments
Body
CustomerID
CustomerUserID
DynamicField
HistoryComment
HistoryType
InformAgent
InvolvedAgent
IsVisibleForCustomer
MarkAsImportant
Messages
OwnerID
PriorityID
QueueID
RelevantKnowledge
ResponsibleID
SenderType
ServiceID
SLAID
StandardTemplateID
StateID
Subject
Title
TypeID

Forms###AgentFrontend::Ticket::Action::Merge

Configurable form for the Merge Ticket action.

Link to the reference of the system configuration:

Forms###AgentFrontend::Ticket::Action::Merge

Possible values for the Name key of the form field:

AddMessage
Body
DynamicField
From
HistoryComment
HistoryType
IsVisibleForCustomer
MarkAsImportant
Messages
RelevantKnowledge
SenderType
Subject
To

Forms###AgentFrontend::Ticket::Action::Move

Configurable form for the Move Ticket action.

Link to the reference of the system configuration:

Forms###AgentFrontend::Ticket::Action::Move

Possible values for the Name key of the form field:

AccountedTime
AddMessage
Attachments
Body
CustomerID
CustomerUserID
DynamicField
HistoryComment
HistoryType
InformAgent
InvolvedAgent
IsVisibleForCustomer
MarkAsImportant
Messages
OwnerID
PriorityID
QueueID
RelevantKnowledge
ResponsibleID
SenderType
ServiceID
SLAID
StandardTemplateID
StateID
Subject
Title
TypeID

Forms###AgentFrontend::Ticket::Action::Note

Configurable form for the Add Note action.

Link to the reference of the system configuration:

Forms###AgentFrontend::Ticket::Action::Note

Possible values for the Name key of the form field:

AccountedTime
Attachments
Body
CustomerID
CustomerUserID
DynamicField
HistoryComment
HistoryType
InformAgent
InvolvedAgent
IsVisibleForCustomer
MarkAsImportant
Messages
OwnerID
PriorityID
QueueID
RelevantKnowledge
ResponsibleID
SenderType
ServiceID
SLAID
StandardTemplateID
StateID
Subject
Title
TypeID

Forms###AgentFrontend::Ticket::Action::Owner

Configurable form for the Change Owner action.

Link to the reference of the system configuration:

Forms###AgentFrontend::Ticket::Action::Owner

Possible values for the Name key of the form field:

AccountedTime
AddMessage
Attachments
Body
CustomerID
CustomerUserID
DynamicField
HistoryComment
HistoryType
InformAgent
InvolvedAgent
IsVisibleForCustomer
MarkAsImportant
Messages
OwnerID
PriorityID
QueueID
RelevantKnowledge
ResponsibleID
SenderType
ServiceID
SLAID
StandardTemplateID
StateID
Subject
Title
TypeID

Forms###AgentFrontend::Ticket::Action::Pending

Configurable form for the Set Pending Time action.

Link to the reference of the system configuration:

Forms###AgentFrontend::Ticket::Action::Pending

Possible values for the Name key of the form field:

AccountedTime
AddMessage
Attachments
Body
CustomerID
CustomerUserID
DynamicField
HistoryComment
HistoryType
InformAgent
InvolvedAgent
IsVisibleForCustomer
MarkAsImportant
Messages
OwnerID
PriorityID
QueueID
RelevantKnowledge
ResponsibleID
SenderType
ServiceID
SLAID
StandardTemplateID
StateID
Subject
Title
TypeID

Forms###AgentFrontend::Ticket::Action::PhoneCallInbound

Configurable form for the Add Phone Call Inbound action.

Link to the reference of the system configuration:

Forms###AgentFrontend::Ticket::Action::PhoneCallInbound

Possible values for the Name key of the form field:

AccountedTime
Attachments
Body
CustomerID
CustomerUserID
DynamicField
HistoryComment
HistoryType
InformAgent
InvolvedAgent
IsVisibleForCustomer
MarkAsImportant
Messages
OwnerID
PriorityID
QueueID
RelevantKnowledge
ResponsibleID
SenderType
ServiceID
SLAID
StandardTemplateID
StateID
Subject
Title
TypeID

Forms###AgentFrontend::Ticket::Action::PhoneCallOutbound

Configurable form for the Add Phone Call Outbound action.

Link to the reference of the system configuration:

Forms###AgentFrontend::Ticket::Action::PhoneCallOutbound

Possible values for the Name key of the form field:

AccountedTime
Attachments
Body
CustomerID
CustomerUserID
DynamicField
HistoryComment
HistoryType
InformAgent
InvolvedAgent
IsVisibleForCustomer
MarkAsImportant
Messages
OwnerID
PriorityID
QueueID
RelevantKnowledge
ResponsibleID
SenderType
ServiceID
SLAID
StandardTemplateID
StateID
Subject
Title
TypeID

Forms###AgentFrontend::Ticket::Action::Priority

Configurable form for the Change Priority action.

Link to the reference of the system configuration:

Forms###AgentFrontend::Ticket::Action::Priority

Possible values for the Name key of the form field:

AccountedTime
AddMessage
Attachments
Body
CustomerID
CustomerUserID
DynamicField
HistoryComment
HistoryType
InformAgent
InvolvedAgent
IsVisibleForCustomer
MarkAsImportant
Messages
OwnerID
PriorityID
QueueID
RelevantKnowledge
ResponsibleID
SenderType
ServiceID
SLAID
StandardTemplateID
StateID
Subject
Title
TypeID

Forms###AgentFrontend::Ticket::Action::Responsible

Configurable form for the Change Responsible action.

Link to the reference of the system configuration:

Forms###AgentFrontend::Ticket::Action::Responsible

Possible values for the Name key of the form field:

AccountedTime
AddMessage
Attachments
Body
CustomerID
CustomerUserID
DynamicField
HistoryComment
HistoryType
InformAgent
InvolvedAgent
IsVisibleForCustomer
MarkAsImportant
Messages
OwnerID
PriorityID
QueueID
RelevantKnowledge
ResponsibleID
SenderType
ServiceID
SLAID
StandardTemplateID
StateID
Subject
Title
TypeID

Forms###AgentFrontend::Ticket::Action::SmsOutbound

Configurable form for the Send SMS Outbound action.

Link to the reference of the system configuration:

Forms###AgentFrontend::Ticket::Action::SmsOutbound

Possible values for the Name key of the form field:

AccountedTime
Body
CustomerID
CustomerUserID
DynamicField
FlashMessage
HistoryComment
HistoryType
InformAgent
InvolvedAgent
IsVisibleForCustomer
MarkAsImportant
Messages
OwnerID
PriorityID
QueueID
RelevantKnowledge
ResponsibleID
SenderType
ServiceID
Signature
SLAID
StandardTemplateID
StateID
Title
To
TypeID

Possible field names for article actions:

Forms###AgentFrontend::TicketArticle::Action::Forward

Configurable form for the Forward via Email action.

Link to the reference of the system configuration:

Forms###AgentFrontend::TicketArticle::Action::Forward

Possible values for the Name key of the form field:

AccountedTime
Attachments
Bcc
Body
Cc
DynamicField
EmailSecurity
From
HistoryComment
HistoryType
IsVisibleForCustomer
MarkAsImportant
Messages
RelevantKnowledge
SenderType
StandardTemplateID
StateID
Subject
To

Forms###AgentFrontend::TicketArticle::Action::Redirect

Configurable form for the Redirect via Email action.

Link to the reference of the system configuration:

Forms###AgentFrontend::TicketArticle::Action::Redirect

Possible values for the Name key of the form field:

AddMessage
Body
From
HistoryType
Messages
RedirectTo
StateID
Subject
To

Forms###AgentFrontend::TicketArticle::Action::Reply

Configurable form for the Reply via Email action.

Link to the reference of the system configuration:

Forms###AgentFrontend::TicketArticle::Action::Reply

Possible values for the Name key of the form field:

AccountedTime
Attachments
Bcc
Body
Cc
DynamicField
EmailSecurity
From
HistoryComment
HistoryType
IsVisibleForCustomer
MarkAsImportant
Messages
RelevantKnowledge
SenderType
StandardTemplateID
StateID
Subject
To

Forms###AgentFrontend::TicketArticle::Action::ReplyAll

Configurable form for the Reply to All via Email action.

Link to the reference of the system configuration:

Forms###AgentFrontend::TicketArticle::Action::ReplyAll

Possible values for the Name key of the form field:

AccountedTime
Attachments
Bcc
Body
Cc
DynamicField
EmailSecurity
From
HistoryComment
HistoryType
IsVisibleForCustomer
MarkAsImportant
Messages
RelevantKnowledge
SenderType
StandardTemplateID
StateID
Subject
To

Forms###AgentFrontend::TicketArticle::Action::ReplyToNote

Configurable form for the Reply via Note action.

Link to the reference of the system configuration:

Forms###AgentFrontend::TicketArticle::Action::ReplyToNote

Possible values for the Name key of the form field:

AccountedTime
Attachments
AutoInvolvedAgents
Body
CustomerID
CustomerUserID
DynamicField
HistoryComment
HistoryType
InformAgent
InvolvedAgent
IsVisibleForCustomer
MarkAsImportant
Messages
OwnerID
PriorityID
QueueID
RelevantKnowledge
ResponsibleID
SenderType
ServiceID
SLAID
StandardTemplateID
StateID
Subject
Title
TypeID

Forms###AgentFrontend::TicketArticle::Action::ReplyViaSms

Configurable form for the Reply via SMS action.

Link to the reference of the system configuration:

Forms###AgentFrontend::TicketArticle::Action::ReplyViaSms

Possible values for the Name key of the form field:

AccountedTime
Body
CustomerID
CustomerUserID
DynamicField
FlashMessage
HistoryComment
HistoryType
InformAgent
InvolvedAgent
IsVisibleForCustomer
MarkAsImportant
Messages
OwnerID
PriorityID
QueueID
RelevantKnowledge
ResponsibleID
SenderType
ServiceID
Signature
SLAID
StandardTemplateID
StateID
Title
To
TypeID

Forms###AgentFrontend::TicketArticle::Action::Split

Configurable form for the Split Article action.

Link to the reference of the system configuration:

Forms###AgentFrontend::TicketArticle::Action::Split

Possible values for the Name key of the form field:

LinkAs
Messages
ProcessID
Target

Possible field names for the ticket create properties forms:

Forms###AgentFrontend::TicketCreate::Email::CreateProperties

Configurable form for the Properties widget of the New Email Ticket screen.

Link to the reference of the system configuration:

Forms###AgentFrontend::TicketCreate::Email::CreateProperties

Possible values for the Name key of the form field:

AccountedTime
Attachments
Bcc
Body
Cc
CustomerID
CustomerUserID
DynamicField
EmailSecurity
HistoryComment
HistoryType
IsVisibleForCustomer
LinkTicketID
LinkType
OwnerID
PriorityID
QueueID
RelevantKnowledge
ResponsibleID
SenderType
ServiceID
Signature
SLAID
StandardTemplateID
StateID
Subject
To
TypeID

Forms###AgentFrontend::TicketCreate::Phone::CreateProperties

Configurable form for the Properties widget of the New Phone Ticket screen.

Link to the reference of the system configuration:

Forms###AgentFrontend::TicketCreate::Phone::CreateProperties

Possible values for the Name key of the form field:

AccountedTime
Attachments
Body
CustomerID
CustomerUserID
DynamicField
From
HistoryComment
HistoryType
IsVisibleForCustomer
LinkTicketID
LinkType
OwnerID
PendingDate
PriorityID
QueueID
RelevantKnowledge
ResponsibleID
SenderType
ServiceID
SLAID
StandardTemplateID
StateID
Subject
To
TypeID

Forms###AgentFrontend::TicketCreate::SMS::CreateProperties

Configurable form for the Properties widget of the New SMS Ticket screen.

Link to the reference of the system configuration:

Forms###AgentFrontend::TicketCreate::SMS::CreateProperties

Possible values for the Name key of the form field:

AccountedTime
Body
CustomerID
CustomerUserID
DynamicField
FlashMessage
HistoryComment
HistoryType
IsVisibleForCustomer
OwnerID
PendingDate
PriorityID
QueueID
RelevantKnowledge
ResponsibleID
Sender
SenderType
ServiceID
SLAID
StandardTemplateID
StateID
Subject
To
TypeID

Possible field names for knowledge base article actions:

Forms###AgentFrontend::KnowledgeBaseArticleCreate::Properties

Configurable form for the Properties widget of the Create Knowledge Base Article screen.

Link to the reference of the system configuration:

Forms###AgentFrontend::KnowledgeBaseArticleCreate::Properties

Possible values for the Name key of the form field:

Approved
Attachments
Category
DynamicFields
Field1
Field2
Field3
Field4
Field5
Field6
Keywords
Language
State
Title
Valid

Forms###AgentFrontend::KnowledgeBaseArticleUpdate::Properties

Configurable form for the Properties widget of the Edit Knowledge Base Article screen.

Link to the reference of the system configuration:

Forms###AgentFrontend::KnowledgeBaseArticleUpdate::Properties

Possible values for the Name key of the form field:

Approved
Attachments
Category
DynamicFields
Field1
Field2
Field3
Field4
Field5
Field6
Keywords
Language
State
Title
Valid

Possible field names for customer actions:

Forms###AgentFrontend::CustomerCompanyCreate::Properties

Configurable form for the Properties widget of the Create Customer screen.

Link to the reference of the system configuration:

Forms###AgentFrontend::CustomerCompanyCreate::Properties

Possible values for the Name key depend on the available fields in the CustomerCompany###Map configuration array. For the default database back end, these include:

CustomerCompanyCity
CustomerCompanyComment
CustomerCompanyCountry
CustomerCompanyName
CustomerCompanyStreet
CustomerCompanyURL
CustomerCompanyZIP
CustomerID
ValidID

Additional column names which are always available:

DataSource

Warning

In case Multiple Customer User Back Ends are configured, all possible fields must be present in the form configuration in order to be able to modify them. Both configurations must be kept in sync, otherwise it will not be possible to modify the customer records.

Forms###AgentFrontend::CustomerCompanyUpdate::Properties

Configurable form for the Properties widget of the Edit Customer screen.

Link to the reference of the system configuration:

Forms###AgentFrontend::CustomerCompanyUpdate::Properties

Possible values for the Name key depend on the available fields in the CustomerCompany###Map configuration array. For the default database back end, these include:

CustomerCompanyCity
CustomerCompanyComment
CustomerCompanyCountry
CustomerCompanyName
CustomerCompanyStreet
CustomerCompanyURL
CustomerCompanyZIP
CustomerID
ValidID

Warning

Possible field names for customer user actions:

Forms###AgentFrontend::CustomerUserCreate::Properties

Configurable form for the Properties widget of the Create Customer User screen.

Link to the reference of the system configuration:

Forms###AgentFrontend::CustomerUserCreate::Properties

Possible values for the Name key depend on the Customer User Back Ends configuration. For the default database back end, these include:

UserCity
UserComment
UserCountry
UserCustomerID
UserEmail
UserFax
UserFirstname
UserLastname
UserLogin
UserMobile
UserPassword
UserPhone
UserStreet
UserTitle
UserZip
ValidID

For most customer user preference modules registered under CustomerPersonalPreference###* namespace, it is also possible to show dedicated form fields. By default, these include:

Preference_Language
Preference_LoginForbidden
Preference_PGP
Preference_SMIME
Preference_TimeZone
Preference_TwoFactor

Additional column names which are always available:

DataSource

Warning

Forms###AgentFrontend::CustomerUserUpdate::Properties

Configurable form for the Properties widget of the Edit Customer User screen.

Link to the reference of the system configuration:

Forms###AgentFrontend::CustomerUserUpdate::Properties

Possible values for the Name key depend on the Customer User Back Ends configuration. For the default database back end, these include:

UserCity
UserComment
UserCountry
UserCustomerID
UserEmail
UserFax
UserFirstname
UserLastname
UserLogin
UserMobile
UserPassword
UserPhone
UserStreet
UserTitle
UserZip
ValidID

For most customer user preference modules registered under CustomerPersonalPreference###* namespace, it is also possible to show dedicated form fields. By default, these include:

Preference_Language
Preference_LoginForbidden
Preference_PGP
Preference_SMIME
Preference_TimeZone
Preference_TwoFactor

Warning

Possible field names for calendar appointment actions:

Forms###AgentFrontend::Calendar::AppointmentCreate::Properties

Configurable form for the Add Appointment action.

Link to the reference of the system configuration:

Forms###AgentFrontend::Calendar::AppointmentCreate::Properties

Possible values for the Name key of the form field:

AllDay
CalendarID
Description
EndTime
Location
Notification
Recurrence
ResourceID
StartTime
TeamID
TicketPlugin
Title

Forms###AgentFrontend::Calendar::AppointmentUpdate::Properties

Configurable form for the Edit Appointment action.

Link to the reference of the system configuration:

Forms###AgentFrontend::Calendar::AppointmentUpdate::Properties

Possible values for the Name key of the form field:

AllDay
CalendarID
Description
EndTime
Location
Notification
Recurrence
ResourceID
StartTime
TeamID
TicketPlugin
Title

Facebook X LinkedIn