How to define different service request types?

Different job queues and responsible handlers

Service request settings are defined in their settings menu by the administrator (Manage tasks -> Service Requests -> Service Request settings).

The service request functionality is enabled by marking "Service request feature in use" selected (in the "Settings"-tab. The title defines the title of the form that users will see.

In the Logo field, you can upload the image / logo you want to appear on the public form.

In the notification settings you can define cases, when an email notifications should be sent and to whom (request submitter / responsible managers).

In the service request settings following things can be defined:

  • to which queue service request is submitted
  • in which cases an email should be sent (and to which roles)
  • the form of the form
  • roles who can open a service request can be restricted
  • if the observer role users may comment the service request or not
  • which roles can see the service requests with status "Open" in the mobile 
  • which spots are listed on public form ( )


Each separate job queue that is desired for different service requests (such as a "work order") forms its own type of service request ("service request type").

Each service request type may have a different form that will be completed when a new form  is filled. The service request type fields are defined on the service request type form.

For each type of service request, you can also define a process of its own, ie in whose work queue each service request is to be displayed (and where, ie on the mobile or management portal) and who is allowed to edit the service request and who is only to view it.
sreq settings
"Manager role" defines which user role can see and handle service request in web browser (management portal) and "user role" defines the responsible group/work queue the service request will be submitted (this role can see the service request in the mobile app).

You can define the visibility of a service request type on a public form by service request type. The service request type is activated on the public form by checking the "Used on public form" box. Leave the box blank if you do NOT want that type of service request to be active on the public form (you can still use the form within the system).

If it is necessary to some role to see the service request but not to handle or complete the service request, define these roles to "observer role". It is possible to allow observers to comment and add attachments to service request though.  (Tick appicable box "Allow adding comments and attachments")

If you want to define a password for public form you need to create a new public form on "Public forms" tab. On this form you may define which spots will be listed to this form.

Public form means a form at "" or "".
These can be used to submit a service request to the system. The public form should not use service request types that are internal to the company.

For the latter public form you may define a password.

For service request types that are not public, the service request can only be submitted by the user logged in with the mobile application or the management portal.

An unlimited number of different service request types can be made for different forms (e.g. bug report form, safety observation, development idea, quality deviation, etc.) and anyone with a known URL can submit a service request by filling out the form if the service request type is in public form.

The service request submitter selects the correct type of service request according to the type of notification he or she wishes to submit. The selected service request type brings the correct type of form to fill out.

Service request settings


Give the service request a name that the notifier can easily select the correct type of notification
Order The order of different service request types can be specified in the order number of the service request type in the drop-down menu of the application.

1 -appears at the top, 2 -next, below the first, etc...
Description The description of the field may be written down to the registrar. The description will only appear on the public form (Tiketti).
For example, “Use this form to record observations of production equipment faults. Attach an image to the fault report, if possible.”
Is default When specifying a service request type as a default service request, the system always provides the service request type first, which is a good idea to specify the type of notification that is expected to open the most
Selecting a spot is a required  field When selecting this user MUST choose a spot service request is attached to
Manager role This is where the (manager) role is defined, for which the service request type notifications in question are to be displayed in the management portal and which is able to process them in the management portal.
User role This is defining the (mobile) role in to whom the service requests in question are desired to appear in the mobile application and which roles users can handle them in the mobile application.
Manager observers A (manager)role that users can only see the service requests in question in the management portal but cannot edit/process/complete them
Mobile observers A (mobile)role that users can only see the service requests in question in the mobile application but cannot edit/process/complete them
Allow adding comments and attachments The user attached to the viewing (observer) role may comment on the service request and add attachments to it (but not to be acknowledged)
Limit right to create service requests You can manage permissions to create notifications of specified service request by defining the roles who has the rights
Show open service request on mobile This setting brings also open (status) service requests to users of roles defined in the mobile application
Usable in mobile application Brings the service request to the mobile application also
Used on public form Bring a service request type to the public form (Tiketti) so that anyone can open up notifications for this service request. The box must be left blank if the service request type is not wanted to be active on a public form (ie notifications can only be opened inside the system with Spot IDs)
Additional fields For each service request types, a individual form can be created. The basic form already has certain fields (service request title, description field, etc.) ready, but if desired, the administrator can add his own fields to the form
Email notifications settings Define here the email (email address(es), header and body) you want to be sent when a new this kind of service request is creted
Include additional fiels in the email Includes the additional fields also to the email 


Additional fields

The "Fields Keys" tab defines the additional data fields on the form. By default, the form will ask for the name, email address and title of the submitter (mandatory information), as well as the phone number and description of the service request, but additional fields will allow you to create exactly the form you need.

Specify the name of the additional field and the type of field that specifies the type of response to be retrieved from the submitter. For example, you can use these configurations to force the submitter to select an answer from the drop-down menu or to enter a simple number. Other field types are text, long text or yes / no menu.

If you use a yes / no slider, you should clarify in the question which position means which value! (eg switch on the right = Yes)