Processing requests in an external ticket system
Requests for a service can be processed outside UnSpot, in your own ticket system: every request goes out as an email to the address you specify, and the email carries service headers with it — the assignee, the observers, the project ID, the priority level and the due date. That is how the Services module plugs into a service desk you already run, without making employees create accounts in it. The processing method is set per service and is available for all three types — “For employee”, “In the office” and “In meeting room”.
How it works
When an employee submits a request for a service with external processing, UnSpot does three things at once: it stores the request, gives it the “Sent” status immediately and sends an email to the address of your ticket system. From that point the request lives in the external system — UnSpot never comes back to it.
This is a one-way handover, not a two-way integration: the ticket number from the external system does not arrive in UnSpot, the status in UnSpot never changes again, and on the “My service requests” page the employee always sees “Sent”.
| What we compare | Processing inside UnSpot | Processing in an external system |
|---|---|---|
| Assignee | Required: one for all offices or one in every office row | Optional, both service-wide and in office rows: used only as the value of a service header and as an address for the email copy |
| Status of a new request | “New” | “Sent” — final, cannot be changed |
| The “Accept”, “Confirm fulfillment” and “Cancel request” buttons | Present | Absent |
| Changing the assignee inside a request | Available to the Super Administrator and Office manager roles until the final status | Not available |
| Response and completion SLA | Can be set in the service settings | Not available: the form has no SLA section |
| The “Due date” and “Files and images” fields | Work as set in the service | Work the same way: the due date goes out in the X-Duedate header, files as email attachments |
| Status history | Accumulates | A single entry |
| Emails | On creation and on every status change — to the initiator and the assignee | One email on creation — to the external system address |
| Request attachments | Stored in UnSpot, not attached to emails | Attached to the email as files |
| Deleting the service | Blocked while there are requests in the “New” and “Accepted” statuses | Always possible: requests of such a service are never in progress |
Setting up a service with external processing
What you need: the Super Administrator or Offices Administrator role; the “My requests” module enabled (Manage → Company settings → the “Available functionality” block); the email address from which your ticket system creates tickets.
The “Add service” dialog is made of sections that run from top to bottom. It is easiest to start with the last one and choose external processing there: it decides which fields above are required.
- Open Manage → Office management → the “Services” tab and click “Add service”.
- In the “Where to process requests” section choose “In external ticket system” and fill in the integration fields — they are described below. The SLA section disappears from the form at this point.
- In the “Availability” section choose “All offices” or “Selected offices only” and assign an assignee if you need one — see “The assignee and offices” below. The “Send the request email copy to the provider” checkbox is in this section too.
- Choose the “Service type”: “For employee”, “In the office” or “In meeting room”. A hint about the selected type appears under the chips.
- In the “Service details” section fill in “Service” and, if useful, “Service description” — the employee sees them in the request form.
- In the “Service request fields” section decide whether the request form needs “Due date” and “Files and images”.
- Check the “Email structure” block at the end of the form: it shows how the header part of the email will look with the current values of the form.
- Save the service. It appears in the table with “External” in the “Request type” column.
The processing method cannot be changed after saving. In the service edit form the “Service type” and “Where to process requests” chips are read-only — only the remaining fields can be changed, including availability in offices and the assignees. To move a service from internal to external processing you have to delete it and create it again, and a service with internal processing can only be deleted once all of its requests have reached the “Done” or “Cancelled” status. Plan this before the first save.
The assignee and offices
With external processing the assignee is needed not to work on the request but for the email: their address goes out in the X-Assignee header and, if the copy is enabled, in the Cc field. It is set in the “Availability” section in one of two ways.
| Mode | What to fill in | Who ends up in X-Assignee |
|---|---|---|
| “All offices” | A single “Assignee” field — optional | That assignee — for requests from any office |
| “Selected offices only” | Rows of “Office” and “Assignee”; a new row is added with the “Add office” button. The office is required, the assignee in the row is not. Each office can appear in one row only | The assignee of the request’s office. If no assignee is set for that office, the assignee of the parent office is used — one level up. If there is none there either, the header is not sent |
The office of a request is determined by its object: for an “In the office” request — the office of the desk, meeting room, parking space, locker or point of interest; for an “In meeting room” request — the office of the meeting room; for a “For employee” request — the office the employee chose in the form. In the “Selected offices only” mode employees see the service only in the listed offices and in their direct child offices.
An assignee in an office row is required only for processing inside UnSpot. If an employee is blocked, UnSpot removes them from the service-wide “Assignee” field and from all office rows on its own; if an office is deleted, its rows disappear.
Integration fields
| Field | Required | What it controls |
|---|---|---|
| “Email of the external ticket system to send requests to” | Yes | The only recipient of the email. Use the address from which your ticket system creates tickets |
| “Assignee” (the “Availability” section) | No | Their address is passed in the X-Assignee service header. For a service with external processing the assignee is optional — unlike an internal one — both in the service-wide field and in office rows |
| “Request progress observers” | No | Their addresses leave for the external system: in the X-Observers header, comma-separated, or, if the copy to observers is enabled, in the Cc field |
| “Project or task ID” (optional) | No | Free text up to 255 characters, passed into the X-Project-ID header unchanged. The hint in the interface suggests the formats PROJECT-123, support, AbCf-03 |
| “Request priority level” (optional) | No | Free text up to 255 characters, passed into the X-Priority header unchanged. The hint suggests Low / Medium / High / Critical or the format used by your own service |
| “Send the request email copy to the initiator” | No | Adds the author of the request to the email copy |
| “Send the request email copy to the provider” (the “Availability” section) | No | Adds the assignee of the request — the service-wide one or the office one — to the email copy |
| “Send the request email copy to observers” | No | Adds the observers to the email copy instead of the X-Observers header. The checkbox is available only when at least one observer is selected |
UnSpot does not validate the values of “Project or task ID” and “Request priority level”: this is free text passed into the email header byte for byte. They will work exactly as far as your ticket system is able to parse them — check its email processing rules before filling the fields in.
Request fields and SLA
The “Service request fields” section works for external processing just as it does for internal: the “Due date” and “Files and images” fields each have a switch and a “Mandatory” checkbox. A field can be marked mandatory only while it is enabled. For an “In meeting room” service “Due date” is always enabled and mandatory.
- “Due date” — the date the employee sets in the request goes to the ticket system in the X-Duedate header.
- “Files and images” — the files the employee attaches are attached to the email. If the field is off, no file can be attached to the request.
SLA is not available for external processing. As soon as “In external ticket system” is selected in the “Where to process requests” section, the section with the “Response SLA” and “Completion SLA” switches disappears from the form: response and completion times are tracked by your ticket system, not by UnSpot.
What the email carries
The subject of the email is the service name, with no date and no request number. The body contains the heading “Service request submitted”, a block with the object data (for “In meeting room” requests — the date, the meeting name and the organiser; for “In the office” requests — the place and the office), the request block itself (service, request text, assignee, status, comment) and a “Go to UnSpot” button leading to the request card. Files attached by the employee are attached to the email.
Beyond the visible part, the email carries service headers — the ticket system sorts requests by them:
| Header | Value | When it is sent |
|---|---|---|
| X-Assignee | The address of the request’s assignee: the service-wide assignee or the assignee of the request’s office | If the request has an assignee and they are active |
| X-Observers | Observer addresses, comma-separated | If observers are set and the “Send the request email copy to observers” checkbox is off |
| X-Status | The constant value New | Always |
| X-Unspot-ID | The request identifier in UnSpot | Always |
| X-Priority | The value of the “Request priority level” field | If the field is filled in |
| X-Project-ID | The value of the “Project or task ID” field | If the field is filled in |
| X-Duedate | The due date of the request — date and time in ISO 8601 format with a time zone offset: YYYY-MM-DDThh:mm:ss±hh:mm | If the “Due date” field is enabled for the service and the employee set a due date |
The addresses of the assignee and the observers leave for the external system in any case — only the way changes. The X-Assignee header is sent regardless of the copy-to-assignee checkbox. Observers go either into the X-Observers header or — with the copy to observers enabled — into the Cc field, and then the email has no X-Observers header. Take this into account in your ticket system parsing rules. If the work addresses of your employees must not leave the company perimeter, do not assign an assignee and observers to services with external processing.
The value of the “Request priority level” field is passed into the X-Priority header unchanged. If you enter word levels such as “High” or “Critical”, make sure your ticket system parses text values of that header.
The “Email structure” block in the service form is an outline, not an exact copy of the email. It takes its values from the form, so in the “Selected offices only” mode the X-Assignee line reads “not specified”: the office assignee is determined when the request is created. The X-Observers line in the block is filled in even when the copy to observers is enabled, although in that case the email does not get this header. The X-Duedate line shows “<Due date>” if the due date field is enabled for the service.
Email copies and the reply address
Copies are sent in the visible Cc field: every recipient sees the addresses of the others. There are no blind copies. UnSpot removes duplicate addresses: if, for example, the initiator of the request is also its assignee, they get a single copy. Only active employees are put into the copy — a blocked or deleted initiator will not receive the email.
The reply address of the email is the address of the request initiator, if it is known — so a reply from the ticket system reaches the employee directly. Requests submitted by QR code without signing in have no initiator: such an email goes out with no reply address, and there will be nobody to answer. Keep this in mind if you enable external processing for a public service.
What happens to the request after it is sent
- The request is stored in UnSpot and is visible on the “Service requests” page alongside the others.
- Its status is “Sent”. That status is final: such a request has no processing buttons, and neither the status nor the assignee can be changed.
- The status history consists of a single entry — the sending itself.
- The email goes out once, at the moment the request is created. There will be no follow-up emails for this request.
- The due date, if set, is shown in the request card and in the “Execution” column of the list.
- Attachments stay available for download from the request card in UnSpot.
Things to keep in mind when setting it up
| Detail | How to work with it |
|---|---|
| The “Sent” status means UnSpot has sent the email. UnSpot receives no delivery confirmation and does not reflect one in the request | Track incoming requests on the ticket system side, not by the status in UnSpot |
| The handover is one-way: the ticket number from the external system does not come back, and the status in UnSpot is not synchronised | If the employee needs the ticket number, set up an auto-reply on the ticket system side — the reply address of the email leads to the request initiator |
| The email subject is identical for all requests of one service | Set your ticket system parsing rules on the X-Unspot-ID header, not on the email subject |
| Observers arrive either in the X-Observers header or as a copy, depending on the checkbox | Decide on the “Send the request email copy to observers” checkbox before setting up the parsing rules, and do not change it without updating those rules |
| SLA is not available for external processing | Set response and completion times in the ticket system itself |
| Services created before the “Service request fields” section appeared have the “Files and images” field turned off | If employees need to attach files to requests, enable the field in the service settings |
| The processing method is set once, when the service is created | Decide before the first save; to switch, delete the service and create it again |
| The request form does not say that the service is processed in an external system | Write about it in the “Service description” field — it is shown to the employee under the selected service |
Related articles
- Service requests: overview — which service types exist and which to choose
- Processing service requests — how requests are processed inside UnSpot
- “For employee” requests: setup — setting up “For employee” requests
- “In the office” requests: setup and QR codes — setting up “In the office” requests and QR codes
- “In meeting room” requests: setup — setting up “In meeting room” requests
