Wolken Tickets
The Wolken Tickets source ingests the incidents and service requests of a Wolken ServiceDesk instance. Each ticket becomes one record in the pipeline, and its contents are uploaded to a new agent session for processing. The document carries the ticket subject, its description, and its conversation notes, so an agent can find past tickets similar to a new issue through semantic search rather than by matching ticket numbers.
Every ticket document also carries the ticket classification fields, such as status, priority, category, and team, as metadata for attribute-based filtering.
Authentication
Before you create the pipeline, obtain the Wolken API endpoint, tenant domain, OAuth client ID, service account, auth code, and refresh token from your Wolken administrator or Wolken support. There is no Vectara-hosted flow for issuing these credentials. These are the same credentials the Wolken knowledge-base and Wolken Forms sources use, and the same token flow applies.
Despite its name, auth_code is not a browser OAuth authorization code. It is
sent verbatim as the Authorization header on the token request, so include any
scheme prefix Wolken issues it with, typically Basic <base64>.
Configuration
The connector requires credentials with read access to the incident and service request listing, detail, and notes endpoints.
SOURCE FIELD (WOLKEN TICKETS)
Code example with json syntax.1
Fields
| Field | Required | Description |
|---|---|---|
type | Yes | wolken_tickets. |
base_url | Yes | Base URL of the Wolken API, for example https://example-api.wolkenservicedesk.com. |
domain | Yes | The value of the domain header issued with your Wolken API credentials. Wolken deployments vary in whether this is a tenant name or a full hostname, so use the exact value from your credential handoff. |
client_id | Yes | Wolken OAuth client ID. |
service_account | Yes | Wolken service account the API calls run as. Sent as a header on API requests. |
auth_code | Yes | The auth code Wolken issues for the instance, used with refresh_token to obtain access tokens. Sent verbatim as the Authorization header on the token request, typically in Basic <base64> form. Encrypted at rest and never returned in responses. |
refresh_token | Yes | Long-lived refresh token exchanged for access tokens. Encrypted at rest and never returned in responses. |
request_types | No | The Wolken request types to ingest, incident, service_request, or both. When omitted or empty, both are ingested. |
backfill_window | No | An ISO-8601 duration bounding how far back ingestion reaches on the first run and on every full_refresh run, for example P90D. Tickets whose last update is older than this duration before the run are not ingested. Days are the largest supported unit. A zero or negative duration is rejected. When omitted, the entire ticket history is ingested, which on a large instance can take a long time. An update cannot return this field to its unset state. A null value in an update is ignored and the stored value is kept. To unset it, replace the pipeline with PUT /v2/pipelines/{pipeline_key} using a configuration that omits it. |
status_ids | No | Wolken status IDs to restrict ingestion to. Status IDs are specific to your Wolken deployment. When omitted or empty, tickets of every status are ingested. Unrecognized status IDs match no tickets. The filter applies to each ingested request type separately, so verify the IDs are valid for both incidents and service requests when both are ingested. A ticket that leaves the configured statuses keeps its last indexed content until it returns to one of them. |
note_response_type_ids | No | Wolken response type IDs selecting the notes included in each ticket document. When omitted, notes of every response type are included. When empty, notes are not ingested. Configure only response types the credentials can read, because a ticket whose notes cannot be read is not ingested. An update cannot return this field to its unset state. A null value in an update is ignored and the stored value is kept. To unset it, replace the pipeline with PUT /v2/pipelines/{pipeline_key} using a configuration that omits it. |
ticket_url_template | No | Template for each ticket's portal URL. The {ticket_id} placeholder is replaced with the ticket's numeric ID. When omitted, records carry no URL. |
How records are fetched
Each run lists the tickets whose modification time falls in the run's change window, reads each listed ticket's details and notes, and composes them into a single HTML document per ticket. Adding a note updates a ticket's modification time in Wolken, so note activity re-ingests the ticket.
Record IDs take the prefixed display form of the ticket number, INC3040127
for an incident and SR3040701 for a service request.
Every note on a Wolken ticket carries a response type that classifies it, for
example as an internal work note or an outbound comment to the requester. Use
note_response_type_ids to restrict the document to specific classes of notes.
Internal work notes often carry the resolution detail that makes a past ticket
useful to retrieve, and they can also carry content not intended for
requesters, so choose the note types to match the audience of the corpus.
A ticket whose notes cannot be read is not ingested without them. The record fails and is retried, so grant the credentials read access to the notes of every ingested request type.
A ticket updated while a run is in flight can, in rare cases, be missed by that
run. It is ingested on its next update or on the next full_refresh run.
Deletions are not propagated. A ticket deleted or restricted in Wolken after ingestion keeps its last indexed content.
Source metadata
Each record carries source metadata that the connector resolves at fetch time.
system_metadata:
| Key | Description |
|---|---|
title | The ticket subject. |
url | The ticket's portal URL, from ticket_url_template. Absent when no template is configured. |
created_time | The ticket creation time as Wolken reports it. |
updated_time | The ticket's last modification time as Wolken reports it. |
user_metadata carries the ticket classification and participant attributes
for attribute-based filtering. Every key is absent when Wolken does not report
a value for it.
| Key | Description |
|---|---|
wolken_ticket_type | The request type of the ticket, either incident or service_request. |
ticket_id | The numeric Wolken ticket ID. |
status_id, status_name | The ticket status. |
sub_status_id, sub_status_name | The ticket sub-status. |
priority_id, priority_name | The ticket priority. |
impact_id, impact_name | The ticket impact. Incidents only. |
urgency_id, urgency_name | The ticket urgency. Incidents only. |
origin_id, origin_name | The channel the ticket was raised through. Incidents only. |
category_id, category_name | The category the ticket is filed under. |
sub_category_id, sub_category_name | The sub-category the ticket is filed under. |
item_id, item_name | The catalog item the ticket was raised against. |
team_id, team_name | The team the ticket is assigned to. |
unit_id, unit_name | The organizational unit of the ticket. |
requester_id, requester_name, requester_email | The person the ticket was raised for. |
employee_id | The requester's employee ID. Service requests only. |
creator_id, creator_name | The account that created the ticket. |
assigned_user_id, assigned_user_name, assigned_user_ps_no | The Wolken user the ticket is assigned to. assigned_user_ps_no carries the assignee's personnel number as configured in your Wolken deployment. Some deployments populate it with an email address. |
last_updated_by, last_updated_by_user_id | The account that last modified the ticket. |
closed_at, resolved_at | The times the ticket was closed and resolved. Values Wolken serves as yyyy-MM-dd HH:mm:ss or yyyy-MM-dd HH:mm UTC timestamps are normalized to RFC 3339, for example 2026-08-23T04:15:49Z. Any other value is indexed verbatim. |
attachment_names | The names of the ticket's attachments, comma separated. Attachment content is not ingested. |
flex_<name> | One key per classification flex field on the ticket, for example flex_location. |
acl_metadata reports org_wide_access as READER. Wolken tickets carry no
per-principal grants readable through the case API, so the principal buckets of
the source-independent
ACL metadata shape are left
null. Restrict the corpus itself to the audience the tickets are appropriate
for.
Incremental sync
When sync_mode is incremental, which is the default, each run reads only
the tickets updated since the previous run. The first run, and every
full_refresh run, reaches back over the backfill_window duration instead,
or over the entire ticket history when backfill_window is not set.