The knowledge base is a collection of all the information gathered during the analysis and resolution process of demands. The knowledge base is structured as a list of articles.
The knowledge base is a research and analysis optimization tool. The items found in the knowledge base are “ready to send” solutions based on clients previous issues or errors.
The clients may also consult the knowledge base articles that are related to a service offered on the Portal. Clients can use the knowledge base to try to solve their problems before contacting the support team.
In addition to basic information (name and resolution), a knowledge base article can be broken down as follow :
- Availability: Public (visible on the portal), private or awaiting approval.
- Keywords: these are words that the system compares with words in the request summary to propose an article when it matches.
- Services: to associate a knowledge base article to the proposed service offered in the client Portal.
- Attachments: to attach files to the knowledge base article.
Requuest introduces a validation process for knowledge base content. Following its creation, knowledge base articles awaiting approval cannot be proposed as a solution, if the content is not validated by the knowledge base manager. This will significantly reduce the number of duplicates and greatly improve the content quality.
Yes. Requuest allows the suggestion of the knowledge base articles in the tickets. This is done by comparing words in the tickets summary with all the existing knowledge bse keywords. If a match is found, the system adds the knowledge base article to the proposed solutions list.
Configuration Items & CMDB Structure
As referenced by ITIL, a CI (Configuration Item) is a component or an active service whose provision require IT service management. This may represent IT services, hardware, software, sites, formal documentation, such as process documentation and Service Level Agreements, suppliers, etc.
The CI folder is a grouping logic of CIs based on specific context/requirements. This concept is not associated with any categories. For management purposes, several CIs from different categories can perfectly coexist in the same CI folder.
For Example :
- You have three CIs in three different categories like: CI ‘’Server Test’’ from category ‘’Servers’’, CI ‘’Application Test’’ from category ‘’Software” and CI ‘’Test Licence Contract” from category ‘’Licence Contracts’’.
- You can associate your three CIs to the same folder ‘’My CIs’’ in the CMDB, even if they do not belong to the same CI category.
A major advantage of using folders is to apply security levels to groups of resources to meet management/access needs. For example; a group of inventory managers can be the only ones allowed to create, update or delete records from the CMDB.
The CI category is the entity responsible for the structure or the framework of the CI by associating attributes. Once the category attributes are configured, the CI created and associated to that category inherits its attributes systematically.
- For the “Server” category, you will define attributes: ‘’Serial Number”, ‘’Model’’, “Make”, etc.
- You create a CI “Test Server” and you associate it to “Server”.
- In the CI “Test Server” information, you must fill out the attribute fields configured for the category “Servers”.
Tickets & Defining CI
A CI can be categorized with the following characteristics (see “CI Category”):
- Name: CI name.
- Status: decides if the CI is active or inactive.
- State: customized list of CI states as needed.
- Record: can be its location, its site, its type, or other in the structural CMDB logic.
- Category: can be hardware, software, documentation or other according the structural CMDB logic.
- CI Owner: CI resource manager (example: approving CI changes).
- Associated client: client using the CI.
- Associated enterprise: enterprises that may impact the CI availability.
- Dependant CIs: CIs who depend on current CIs.
- Impacted CIs: CIs who impact current CI.
- Associated tickets: ticket list which the current CI is an attached CI.
- Attached files: attached files to the CI.
- Activities: history of the changes made to the CI.
CIs can be attached in different ways in the tickets/tasks :
- Associated CIs: using the fields that are provided by the system for this purpose.
- CIs as custom fields: using the custom fields of Type CI or Multiple CI
As a result, business rules can be executed from the CI values in tickets or tasks.
CMDB Search Options
There are 2 types of searches in the CMDB:
1. The simple search (from the CI menu):
· Quick Search: interrogates the CI “Name” and Number’’ attributes.
· Full Text Search: searches in all the CI attributes.
· Client Search: used to find a particular client CI.
2. The Advanced Search (from the search menu under CMDB):
· The Search condition(s): the criteria must be met in order to get the results.
· The Search results: provides all the CIs that meet the search conditions.
· Batch Actions: a very effective tool to execute batch actions (updates or changes) on all CIs found by the search.
Synchronized fields are used in the requests templates to return the clients or CIs record faster.
All types of fields can by synchronize. The field source: customer record or CMDB must be identical as the synchronized field type.
A ticket creation synchronization is done with the client’s record and with the CMDB when the first CI is associated to the ticket.
The synchronized fields are associated to the client’s record or CI attributes in the CMDB.
Views & CMDB Options
With the relationships displayed of the CMDB structure, it is possible to navigate the entire CMDB hierarchy in order to show all relationships between targeted CIs.
There are many possibilities in terms of creating a CI:
1. Creation/update manually:
- By creating a CI from the dedicated UI in Requuest.
- By copying all the information from a CI.
- By copying only a relationship from a CI (in case of a replacement).
2. Creation/ update by batches :
- By using the .csv template.
- By using the file ‘’import.config’’ (mapping xml).
In addition, it is possible to automate the creation/update by scheduling Windows tasks which import the data from one source. (.csv or import.config as needed).
We can find an “Activity” section at the bottom of each CI form, which details all the operations that have been made by the system or manually by the resource. You can find in this section all field updates.
Yes. Requuest is quite flexible in that regard. You can profit from the concepts that are already in place to monitor the quality of responses and resolutions of requests. In addition, you can define your own indicators to target the aspect of the service you wish to measure.
Requuest comes with a dashboard to view different types of statistics to help with decision making. These come by default with the system in forms, reports and cover all types of metric requirements.
A performance indicator, “KPI”, is a measurement or a group of measurements aiming a critical aspect of the overall performance of the organization.
The performance indicators are divided into three global types:
• Warning: This type of indicator indicates an abnormal state in the monitored system requiring an action, immediate or not.
• Equivalent: This type of indicator which is closely linked to goals is as a compass to a manager. It informs the status of the monitored system in relation to the objectives pursued.
• Anticipation: A good Dashboard is also an instrument for foresight. It allows you see further than the tip of your screen and consider a better understanding of the actual situation.
In other words, the set-up of performance indicators will improve:
• The visibility of your performance and strategic objectives.
• The speed of your decision making.
• Efficient piloting by Management.
• Teamwork based on shared and measurable objectives.
From the portal:
· A manager can see the tickets created for the enterprise or the enterprises where he was assigned as manager. He can also group or sort by the columns on the portal grid.
· A manager can add notes to the enterprise tickets or to the enterprises where he was assigned as manager.
This option is very interesting for many reasons, such as:
· It allows a view of the enterprise’s overall situation in regards to the created tickets on the portal.
· In terms of licenses, a manager can release a concurrent license that could be used by another resource from the portal.
The functionality of the Enterprise Manager on the Portal allows a manager to view and track the requests from enterprises to which he is assigned as manager from the portal.
The Manager can then track created tickets by the enterprise resources. (Enterprises that may represent departments, division, institutions, etc.).
Messages & Notes
You can easily add a client note and view it, in the client recorded list. To do so, you simply click on the add button at the top of the screen, next to the client name, when creating a ticket.
It is also possible to add a note directly in the client’s manager, where you can consult all notes.
In Requuest, the Interaction module is the part that is responsible for all the automation that executes the business management rules.
This module aims to simplify the management of automated actions according to specific conditions.
The main objective is to take over as much of the manual work performed by the resources and minimize errors related to human intervention.
Interaction can be divided in four parts:
- The information: the record, the target and the name of the interaction.
- The condition(s): a set of logical expressions that the system verifies when running the action(s).
- The action(s): instructions to run if conditions are validated.
- The rerun: The type of control of the interaction execution (once only, at each save or by a selected time interval.)
There are no limits to the actions that can be performed. A set of conditions can generate many actions. Here are some:
· Send email from a ticket or specific to a group or a resource of the application.
· Define a request field value, a parent ticket, the referred ticket or from the client record.
· Create a ticket or a task.
· Concatenate or calculate a date
· Sent a survey to the principal client of the ticket.
· Call a web service
Interaction is a very useful tool when it comes to programing automatic actions. In other words, with Interaction, it is possible to:
- Send emails to resources, groups of resources, clients or specific addresses. Example: notify a manager of an exceeded deadline of the ticket’s resolution.
- Set or change the value of one or more selected system/custom fields. Example: change the status of a request to “resolved” after the client’s approval.
- Create tickets or tasks based on condition(s). Example: create an approval task for the manager for an equipment loan request.
- Calculate date values based on other deadlines. Example: define a shipping date based on the confirmation date of the order plus two working days.
- Send satisfaction surveys. Example: At the closing of a ticket, send a survey to the client with predefined questions to measure his feedback.
There are three ways to automatically generate data in any ticket fields:
· By setting linked fields to a client’s record with associations in the template. This will generate dynamic data and associate the ticket to the client.
· By using Interaction to act on a condition and chose the value that will be added to the field.
· By setting a default value when at the request’s configuration.
A task is composed by the following elements:
• Basic information: summary, description, step and queue.
• The client(s)/approver(s): depending on type.
• Monitoring indicators: Significant dates, creator and the resource that last modified the task.
• Assigned resources/groups: depending on management need.
• Other sections: references, attachments, notes and emails and any other customized section.
The concept of tasks in Requuest was built to allow the creation of complex running processes in order of predefined steps or to dynamically insert new tasks.
Tasks are divided in two types:
• Approval tasks: approval requests normally sent to managers.
• Operational tasks: operational tasks that, according to their role, are a part of all resources responsibilities.
The main benefit of using tasks is to automate operations that are manually executed. This automation has the positive impact of reducing the time spent manually distributing and monitoring tasks. Also, tasks can be an excellent way of collaborating with multi-departments on the same request, while having only one resource responsible for the ticket.
It is possible to insert a task in a ticket by:
• Associating a task to a request: this will associate the task directly to the ticket at is creation from a request.
• Manually create a task directly in the ticket: if needed, a task can be manually created in the ticket.
• Insert a task using interaction: depending on the conditions, a task can automatically be associated to a ticket with the help of Interaction.
Ticketing Tips & Tricks
· You are unsure of a client’s problem at the beginning of a call? No problem! With the “+” in the ticket creation toolbar, you will be able to open a ticket and start documenting before categorizing it.
· You added a CI too quickly to your ticket, move your cursor on the client’s name tile and click on “CIs” to view all the inventory items that are available for that client. Select the items by simply clicking on it.
· If your application is not in an auto-assign mode, use the auto-assign button under the assigned resource.
· The automatic timer section, will allow you to calculate the time spent on any ticket. You can start and stop the timer with the play and stop button or simply by entering a start and end date using the + button.
· The client’s role field allows you, at any time, to move up the priority of a ticket based on the established priority levels.
· You are confused by the “Reference to” and ‘’Referenced by” terminology? Referenced by; represents the parent ticket, the main one. Reference to; represents the child ticket of the parent ticket.
You have entered a technical resolution and you want to send it to the client resolution: just click on the arrow between the two boxes to transfer the content from one to the other. You could also copy and paste the content.
You want to assign a ticket to a resource, a group or a request queue without having to open the ticket?
· From the ticket grid, simply click and drag the ticket to the desired group, the resource or the request queue. This replaces the request queue but adds it to the resource/group.
Is it possible to group tickets?
· Yes, just drag and drop the column titles into the grey column heading. You can group as many as you wish.
Is it possible to sort data in more than one column?
· Yes, just click on the column title to have it in an ascending or descending order. You just have to click on a second field, third field, etc.
- 1 click = ascendant sort
- 2 clicks = descendant sort
- 3 clicks = deactivating the sort
Is it possible to preview a ticket?
· Yes, just click on any field with the exception of the ticket number: a preview will appear and will allow you to send an email, write a note and view all ticket notes and tasks.
The ticket types (Incident, Problem, Service request, Change request) are defined as per the ITIL standard which specifies the different processes for each of them. Requuest has also a “Project” type in order to generate larger demands. This one has its own status based on PMBOK and its template is as customizable as all other types of requests.
It is therefore possible for you to manage projects in Requuest without affecting statistics and your incidents service levels.
Ticket Main Grid
Requuest resources can:
· Add/remove columns, including custom fields.
· Group tickets by one or more fields (columns).
· Sort tickets.
· Extract tickets to an Excel spreadsheet.
· Change the view from tickets to tasks.
· Change a normal view to a calendar view.
In the Main Grid, it is possible to:
· Group tickets by column: Example: group by enterprise name, resource name or the selected due date.
· Group tickets according to multiple columns of the grid: we are talking here of multiple groups. Example: grouping by enterprise, and then by the ticket queue.
In the Main Grid, it is possible to:
· Sort tickets according to the Grid columns: Examples: sort by enterprise name, resource name or the selected due date.
· Sort tickets according to multiple columns of the grid: we are talking here of multiple sorts. Example: sort by enterprise, and then by ticket queue.
From the Main Grid, it is possible to export the results in an Excel file which will contain the same columns as the Grid at the time of export.
You simply go to the resource’s “Preferences” and modify the columns in the Main Grid.
It is possible to choose different views for the Main Grid
· Tickets/Tasks: this option lets you toggle between the ticket and the task view or shows a combined view of both.
· Normal/Calendar: lets you toggle between the ticket and the task view or displays the grid in a calendar view containing the ticket/tasks dates that are referenced in the ‘’Calendar’’ section.
Filters & Queues
A queue is like a Windows directory: It is a place where all tickets are placed according to a specific logic.
A queue can be used to represent teams, your process or requests status, your requests, etc.
A request queue can also be used to hide tickets from a group of resources, such as request from complaints or human resources.
It’s a combination of multiple conditions that applies filters to the ticket grid. It is the equivalent of a permanent search, with predefined parameters.
A filter displays only the conditions included.
A filter can be used to display ticket Groups, follow ticket priorities, or specific attributes. There are many reasons to use a filter, but the main one is to find specific tickets to display on screen.
As an administrator, you can create public filters for all your resources such as:
- Main menu
- Ticket Filters
As a resource, you can create private filters that will be only visible for you such as :
- Main menu
- My filters
In the left hand side of the Main menu, you have a section called Filters. To use a filter, you need to click on it and the ticket grid will adjust accordingly.
To view all tickets, simply click on the link none and the previous selected filter will be deactivated and the ticket grid will automatically refresh.
Security Groups allow internal management of the system. It limits resource groups’ access to certain menus and ticket operations.
It also allows association between request queues and resources. Enabling them too only access what they are entitled to.
Requuest search engine is divided into two types:
· Quick search: to quickly find a ticket based on the number, summary or client.
· Advanced search: to build a more advanced search with additional criteria.
This type of search is used for simple searches and does not require complex conditions to achieve the desired result.
Among other scenarios, this search is ideal to use when the ticket number is known in advance.
This search will only give you a result in the tickets that are open at the time of the search.
There are several ways to perform an advanced search in Requuest:
· From the main grid: this type of research proposes predefined fields. It is possible to fill in the information as needed, includes closed tickets and uses the search templates.
· From the “Service Desk Menu” > Search: this is a research that is based on the conditions/actions. The results in this type of search can be subject to “lot actions” if needed.
By resource, it is possible to create search templates that can be reused in the case of recurring researches using the same conditions.
These templates can be accessed from the advance search in the main view. The conditions from these templates can be combined with the values of the predefined fields in the advance search.
The search template can be used from the “Advanced search” on the main grid. The search template allows you to use basic criteria’s for recurring searches.
For example, if you regularly want to query open tickets from the previous week. You can build your conditions in your search template and simply modify the start and end dates for the desired period.
It is possible to create customized search templates by resource, based on desired conditions.
Notes & Emails
Public Notes and Emails allow you to exchange information with clients. It can be questions, additional information or simply a note to show the progression or actions taken in a ticket.
Each note you can be set to private or public. The private notes are available in the application and provide information about statuses and follow ups. The public notes are available on the portal for customers and enable the exchange of information between you and them.
It is also possible to add follow up dates to your notes to get a reminder when needed.
You can add a note or send an e-mail from the ticket toolbar. It is also possible to do it from the buttons in the preview of the ticket in the main grid.
You find the notes and letters in the section of the same name in the ticket. They are also available from the main grid in the summary of a ticket.
Two types of notes are by default in Requuest: "Meeting" and "Phone Call". You can add all other type needed to your ticket management by the list items manager.
Any resource on the application can use the calendar views.
The queues and the ticket filters allow the filtering of the calendar view
No, the two calendars are not linked. Nevertheless, it is possible to send an email notification for every item appearing in the Requuest calendar. The user can then create a rule in his Outlook calendar to integrate the item in it, from the email received.
The alert creations you have to do it by Interaction. That configuration must be done by the Requuest administrator.
The colors represent the ticket types suggested by Requuest and visible in the calendar: “Service Requests, Incidents, Problems, Change Requests Projects, and Projects.”
Chat, Assignement & Activities
It is possible to communicate directly with one of your colleagues thanks to the “Chat” module located on the top left hand side of the ticket grid.
Online resources will be displayed by a green icon, and you just select one by clicking on it to open the chat window.
Many individual discussions can simultaneously be opened. But, no group discussion is available at this time.
Found at the bottom of each ticket is an « Activities » section that details all the operations made in that ticket, it includes all the interventions made by the system or manually by the resource. We can find field updates, added notes, sent and received emails for that ticket, and also the information related to the time sheet.
Because the system administrator has already configured the system so that the resource that creates a ticket becomes automatically assigned to that ticket.
In Requuest, the service catalog structure is in 3 levels: category, services and requests. Once the structure is defined and completed, it will be automatically publish on the client portal as a web view.
Defining a service catalog is a process that must be maintained. There are many ways to structure the information depending on your enterprise’s needs/workflows/forms/rules. You need to:
· identify your company’s services (technical, internal, external, etc.);
· identify the requests related to these services;
· identify if you need custom fields to create forms for specific requests;
· identify task to create a tasks template to associate them to your different requests
The priority matrices allows you to determine the priority of a ticket based on its impact and urgency, and also manages the ticket based on the Service Level Agreements (SLA) function agreed upon with your clients.
It defines the calculated due date and the response date allowing resources to prioritize their tasks base on the importance of client tickets in compliance with their client contractual agreements.
Yes , specific matrices are also available on each ticket template and will override the matrix of the ticket type, if enabled.
For example: It generates a specific priority for all incidents but when a server goes down, the priority will move up to a P1, regardless of the matrix standard.
The priority is mainly defined by impact and urgency. The matrices are defined by the type of ticket: project, incident, service request, change request and problem.
The client role can also factor into change too assigned priority. For example: If a client is a Vice President or a Senior Manager.
Yes, the impact and urgency are specific criteria’s in your environment, and can be configured in the Management menu of the application.
You can add impacts and urgencies or modify them to better reflect your reality.
Custom fields’ list types are configurable fields that allow the collection of information according to the predefined values by the administrator.
It can be a dropdown type list or a CI type list, client, CI category, etc. The later one allows you to provide the end-user with the values from a list to perform data collection.
Items from a dropdown type list menu are defined in the Management > List Items menu and can contain all the values selected by the Administrator.
It is possible to filter these items by using the filters’ list in Management > List Filters. However, both list types must be found at destination in order for the filters to be functional.
For items from CIs, configuration items found in the CMDB, it is possible to target only certain items, based on their attributes. Example: Only CIs from the telephone equipment category whose status specifies that they are available at inventory.
If a custom field is created from a dropdown menu list, it is important to have created these elements in the management menu before creating the custom field:
· List items
· List filter (if applicable)
For the CIs type lists, there are no steps required before creating a custom field.
As with any other custom fields, it is possible to use a field of this type in the client record, as a CI category attribute and on demand templates, both for tickets and tasks.
Service Level Management
An SLA (Service Level Agreement) is a written agreement (not a contract) between a service provider and one or more clients.
It covers one or more business services and describes the service levels provided to one or more business organizations (availability, capacity, security and continuity of service).
SLA (Service Level Agreements) defines specific objectives on which the performance of the services is measured. SLM (Service Level Management) maintains and improves the quality of IT services through a constant cycle of agreements, monitoring statistical reports in the achievement of objectives.
The return on investment is very interesting:
• Identify and define customer needs.
• Provide a framework of understanding for both parties.
• Simplify complex problems.
• Encourage dialogue in conflict.
• Eliminate unrealistic expectations.
• Being used as a marketing tool by commercial and technical services.
• Transform an obligation of means by an obligation of result.
Indeed, Requuest provides level management services related to your demands and tickets. In addition, it provides significant flexibility to allow you to better adapt this management to your business reality.
To support optimal quality of service, Requuest provides two indicators related to the service level management:
• Response time: this indicator is available to help you control the management of the Taking Charge Date of the demands by your teams.
• Resolution time: this will allow you to have a clear vision on the time taken to propose a resolution in line with the clients’ expectations.
• A priority matrix where you can customize the values of the two indicators to support your SLA agreement with your clients.
Absolutely. In order for you to expand the range of possibilities, Requuest can manage the service levels in two ways:
• Service levels generic settings: this aims to apply global levels of services for all your needs according to priority.
• Specific service level management: handles exceptions for any request that is beyond the scope of the overall service level management.
When you want to create a new ticket for an unavailable enterprise, a message will appear on the screen with the unavailability explanation.
If the association is allowed, the enterprise will appear in the ticket in red for future reference.
Depending on what the administrator has defined as a parameter at the creation of the status. Some may enable or disable the association.
When creating a ticket with an unavailable enterprise, a message will appear on the screen with the unavailability explanation (for example. breach of contract) and will notify the resource to let them know if the association is allowed or not.
Yes, the administrator can add a reason for unavailability if needed. You can manage statuses/description in the list items management.
For every new status, the administrator must define if the client can or cannot be associated to a new ticket and add a comment that will appear on the screen if a resource tries to add him to a ticket.
The unavailability status applies to enterprises and impacts clients associated with that enterprise.
The unavailability status allows you to make “Enterprise” and his associated clients unavailable for ticket associations. You can associate this type of status through the enterprise management. This could let you see if an enterprise can receive support or not. For example: if a support agreement is no longer valid.
When an enterprise is unavailable, the resource may need to request billable work because you won’t be able to associate the client to a request or open a ticket.
Yes. The application allows the creation of various enterprises, in order to facilitate the creation of a multi-department structure to help manage all the clients.
You can also use the tickets by “queues” to manage the information you want to access.
Requuest offer the following administrative settings:
- Working hours.
- Service levels indicators.
- Service catalog.
- Application grid
- Additional fields used for client search.
- Import configuration.
This section includes many parameters:
- Queue: the default queue for the new tickets that have no queue assigned in the request template.
- Automatic assignment: to automatically assign tickets to the resource that created them.
- Email template: the email template that will be used by default when sending emails from tickets by the resources.
- Automatic Timer: to automatically start the timer at the opening of a ticket tab.
This section is used to control the sorting of service catalogs on the portal in alphabetical or numerical order.
This section contains many parameters:
- Anonymous client: the client that will be associated to the requests made anonymously from the portal.
- URL: the link to access the service catalog anonymously from the portal.
- Change request in the client file: to associate the client’s information in the change request from the portal.
- Portal grid: controls the ticket grid columns on the portal.
Used to control the columns for the resources at the grid level of the application.
In addition to the default fields, this feature allows to choose two other fields that will be used when searching for a client.
This section allows you to choose the duration of a working day that will be applied on the calculation of the timer within the tickets.
Allows you to set the Client/CI import configuration
This section contains the different system cleaning options:
- Permanently delete all tickets: to remove all ticket from the application, leaving the requests intact.
- Permanently delete all clients: to remove all clients from the application, leaving the resources intact.
- Permanently delete all CIs: to remove all Cis from the application, leaving all categories and files intact.
The roles of the system users are divided into three categories.
In each category, you can create multiple user groups, each one of them have specific rights and views depending on their needs. The outlines of these categories are as follow:
Other possible title:
Self-service client portal
Custom Fields Configuration
Custom fields are configurable fields allowing data collection according to predefined values from the administrator.
It may consist of the following types:
- Integer or Decimal
- Text or Memo
- Date and Time
- Dropdown List, CI List
- CI or Multiple CI
- Resource, Client or Multiple Client
- Label, Rate or Sequence Number
- External data or Attachments.
All custom fields can be used in a client file as an attribute of CI category. On request templates both for tickets or tasks. It can also be use in the survey forms.
Custom fields can be secured in two complementary ways :
· When creating a field, it is possible to assign Groups to it and also make these Groups the only ones enable to view the fields and the data within those fields.
· When using these fields, it is possible to define them as read-only; making sure users will not be able to add any information.
It is possible to apply a filter on the custom field of type text to force a format on the user, assuring information consistency.
· 999-999-9999 or (999) 999-9999 for the telephone number format
· A9A 9A9 for the Postal Code
· CAPS for TEXT, Lower case for text or Capitalization for Text
It is possible to create a custom field type “application” by specifying a path to it. This will open the application by clicking on it from the client record or CI. You can also specify the connection from a specific client or CI record and obtain a quick control button.
Application path: mstsc.exe
Argument : /v:laptopmodel
The parameters are as follows:
- Email account: by default, the account that will be used to receive emails in order to create tickets in the application.
- Customized email tags: allows adding the choice of a tag in the email subject line from within the application.
Currently, there are two types of forms in Requuest:
- The client form in which you add all custom fields that you want to display in the client record.
- Custom field forms, with which you can, for example, sent satisfaction surveys to clients once a demand has been closed.
It is possible to post messages on the portal to inform your customers of system failures, maintenance or even post your working hours. This may help to avoid unnecessary ticket creation, as your customer will be informed that the application is not available for maintenance purposes, for example.
Two different color are used to display the messages; turquoise for information and yellow for alerts.
You can also define a start and end date for each message to appear and disappear on the portal automatically. You can even filter which enterprise will see message.
Under Options menu; preferences. Resources are allowed to customize their tickets and CIs views.
It is also possible to include two additional fields to be searched during a client search.