System Configuration

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.

See also

By using the System Configuration History package, you can easily roll back changes made by users. Contact sales@otrs.com to add this feature to your system.

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.

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

    System Configuration - Search For Setting

  2. Select the setting from the search results.

    System Configuration - Setting Found

    System Configuration - Setting Found

  3. Click on the header of the widget to see the options.

    System Configuration - Setting Expanded

    System Configuration - Setting Expanded

  4. Hover the mouse over the widget body to see the Edit this setting button.

    System Configuration - Setting Hovered

    System Configuration - Setting Hovered

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

    System Configuration - Setting Clicked

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

    System Configuration - Setting Modified

  7. Click on the Save button. If the modification is saved, the widget gets a green border on the left.

    System Configuration - Setting Saved

    System Configuration - Setting Saved

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

    System Configuration - Setting Changes

  9. Review the changes.

  10. You can click on the ⇄ button in the top right corner to compare the changes side-by-side.

System Configuration - Setting Different

System Configuration - Setting Different

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

System Configuration - Deploy Setting

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

System Configuration - Setting Deployed

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

System Configuration - Reset Setting

  1. Click on the Confirm button.
  2. 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.

System Configuration Navigation Tree

System Configuration Navigation Tree

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

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:

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

To import the system configurations:

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

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

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

An Example of the Web Notifications List Screen

Link to the reference of the system configuration:

AgentFrontend::Search###DefaultConfig

The default configuration for the Search Results list.

An Example of the *Search Results* List Screen

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

An Example of the Article Preview in the Ticket List Screen

Link to the reference of the system configuration:

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

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

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.

System Setting with a YAML Value

System Setting with a YAML Value

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.

Error in a YAML Value

Error in a YAML 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 translation files. See the Custom Translation File chapter in the developer manual.

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.

An Example of the *Ticket* Detail View

An Example of the Ticket Detail View

The following system configuration settings are relevant:

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

An Example of the *Dashboard* Screen

An Example of the Dashboard Screen

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

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.

 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.

Available widget names 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

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

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 translation files. See the Custom Translation File chapter in the developer manual.

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 prefix DynamicField_ must be added, for example DynamicField_MyFieldName.

ArticleDynamicFields:
  - <DynamicField_FieldName1>
  - <DynamicField_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.

Form of *Add Note* Action

Form of Add Note Action

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

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

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 translation files. See the Custom Translation File chapter in the developer manual.

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.

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

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:

  • Category
  • Changed
  • Created
  • Language
  • 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.
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 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:

Possible values for the Name key of the form field:

AccountedTime
AddMessage
Attachments
Bcc
Body
Cc
CustomerID
CustomerUserID
DynamicField
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::Customer

Configurable form for the Change Customer action.

Link to the reference of the system configuration:

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:

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:

Possible values for the Name key of the form field:

AccountedTime
AddMessage
Attachments
Bcc
Body
Cc
CustomerID
CustomerUserID
DynamicField
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::Merge

Configurable form for the Merge Ticket action.

Link to the reference of the system configuration:

Possible values for the Name key of the form field:

AddMessage
Attachments
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:

Possible values for the Name key of the form field:

AccountedTime
AddMessage
Attachments
Bcc
Body
Cc
CustomerID
CustomerUserID
DynamicField
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::Note

Configurable form for the Add Note action.

Link to the reference of the system configuration:

Possible values for the Name key of the form field:

AccountedTime
Attachments
Bcc
Body
Cc
CustomerID
CustomerUserID
DynamicField
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::Owner

Configurable form for the Change Owner action.

Link to the reference of the system configuration:

Possible values for the Name key of the form field:

AccountedTime
AddMessage
Attachments
Bcc
Body
Cc
CustomerID
CustomerUserID
DynamicField
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::Pending

Configurable form for the Set Pending Time action.

Link to the reference of the system configuration:

Possible values for the Name key of the form field:

AccountedTime
AddMessage
Attachments
Bcc
Body
Cc
CustomerID
CustomerUserID
DynamicField
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::PhoneCallInbound

Configurable form for the Add Phone Call Inbound action.

Link to the reference of the system configuration:

Possible values for the Name key of the form field:

AccountedTime
Attachments
Bcc
Body
Cc
CustomerID
CustomerUserID
DynamicField
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::PhoneCallOutbound

Configurable form for the Add Phone Call Outbound action.

Link to the reference of the system configuration:

Possible values for the Name key of the form field:

AccountedTime
Attachments
Bcc
Body
Cc
CustomerID
CustomerUserID
DynamicField
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::Priority

Configurable form for the Change Priority action.

Link to the reference of the system configuration:

Possible values for the Name key of the form field:

AccountedTime
AddMessage
Attachments
Bcc
Body
Cc
CustomerID
CustomerUserID
DynamicField
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::Responsible

Configurable form for the Change Responsible action.

Link to the reference of the system configuration:

Possible values for the Name key of the form field:

AccountedTime
AddMessage
Attachments
Bcc
Body
Cc
CustomerID
CustomerUserID
DynamicField
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::SmsOutbound

Configurable form for the Send SMS Outbound action.

Link to the reference of the system configuration:

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:

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:

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:

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:

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:

Possible values for the Name key of the form field:

AccountedTime
Attachments
AutoInvolvedAgents
Bcc
Body
Cc
CustomerID
CustomerUserID
DynamicField
HistoryComment
HistoryType
InformAgent
InvolvedAgent
IsVisibleForCustomer
MarkAsImportant
Messages
OwnerID
PriorityID
QueueID
RelevantKnowledge
ResponsibleID
SenderType
ServiceID
Signature
SLAID
StandardTemplateID
StateID
Subject
Title
To
TypeID
Forms###AgentFrontend::TicketArticle::Action::ReplyViaSms

Configurable form for the Reply via SMS action.

Link to the reference of the system configuration:

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:

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:

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:

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:

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:

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:

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:

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:

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

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.

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:

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_LoginForbidden
Preference_PGP
Preference_SMIME
Preference_TwoFactor

Additional column names which are always available:

DataSource

Warning

In case of Multiple Customer User Back Ends, 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 user records.

Forms###AgentFrontend::CustomerUserUpdate::Properties

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

Link to the reference of the system configuration:

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_LoginForbidden
Preference_PGP
Preference_SMIME
Preference_TwoFactor

Warning

In case of Multiple Customer User Back Ends, 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 user records.

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:

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:

Possible values for the Name key of the form field:

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