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.

Jira Service Managementakenza.atlassian.net

Before you open a ticket

• Check the Status Page. 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 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:

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

Never paste an API key, 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.

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, 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 lacks the scope or the workspace, rather than the endpoint being wrong.

• Who changed something. The audit logs 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.