> For the complete documentation index, see [llms.txt](https://docs.akenza.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.akenza.io/faq/service-desk.md).

# Service Desk

Reach the akenza support team, and give them what they need to help.

The **Service Desk** is the way to reach the akenza support team. Use it to report something broken, to ask a question the documentation does not answer, and to raise requests that need akenza to act, such as a connector for a data source that is not supported yet.

{% embed url="<https://akenza.atlassian.net/servicedesk/customer/portal/4/group/-1>" %}

## Before you open a ticket

* Check the [Status Page](/faq/status-page.md). If an incident is already open on the component you are using, the answer is there and no ticket is needed.
* For a change to the platform rather than a problem with it, use the [feature portal](/faq/request-a-feature.md) instead, where your request can be voted on.

## What to include

A ticket that carries the context below can usually be diagnosed on first reading, rather than after a round trip of questions:

<table><thead><tr><th width="230">Detail</th><th>Why it helps</th></tr></thead><tbody><tr><td><strong>Organization and workspace</strong></td><td>Identifies where to look. The names as they appear in the application are enough.</td></tr><tr><td><strong>The object involved</strong></td><td>The device, data flow, rule, or dashboard, ideally with its ID from the URL or its detail page.</td></tr><tr><td><strong>When it happened</strong></td><td>A timestamp with the time zone, or the range you observed. This is what makes logs searchable.</td></tr><tr><td><strong>Expected and actual</strong></td><td>What you expected to happen and what happened instead, kept separate from your theory of why.</td></tr><tr><td><strong>The exact error</strong></td><td>The full message or HTTP status, copied as text. For API calls, the request you sent and the response you got back.</td></tr><tr><td><strong>How often</strong></td><td>Whether it happens every time, intermittently, or happened once, and when it started.</td></tr></tbody></table>

{% hint style="warning" %}
Never paste an [API key](/device-management/managing-an-organization/api-keys.md), a client secret, a device security key, or a password into a ticket or a screenshot. Support does not need them, and a credential shared this way has to be replaced afterwards. Redact the value and describe which credential it was instead.
{% endhint %}

## Things you can check yourself first

Many reports resolve faster once the obvious layers are ruled out, and the answer is often visible in the application:

* **No data from a device.** The device page shows when the last uplink arrived. If the network shows the message but akenza does not, the problem sits at the connector; if neither shows it, it sits at the device or the network.
* **Unexpected values.** Compare the raw payload against the output of the [device type](/device-management/your-data-flow/device-type.md), which separates a decoding problem from a sensor problem.
* **A rule that did not fire.** Check the rule's condition against the actual message that should have triggered it.
* **A rejected API call.** A `403` usually means the [API key](/device-management/managing-an-organization/api-keys.md) lacks the scope or the workspace, rather than the endpoint being wrong.
* **Who changed something.** The [audit logs](/device-management/managing-an-organization/audit-logs.md) record configuration changes and who made them, which often explains a change in behaviour without a ticket at all.

## Other ways to get in touch

Support is also reachable through the **in-app chat**, which suits a quick question. The Service Desk is the better choice for anything that needs to be tracked, reproduced, or picked up by someone else later, since a ticket keeps its own history.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.akenza.io/faq/service-desk.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.