What to include when reporting an issue

Modified on Fri, 29 May at 10:14 AM

A well-described ticket gets a useful first response. A thin ticket usually triggers a round of clarifying questions before anything can happen. This article lists what to include when you report an issue, so the first reply gets you closer to a resolution.

For how to actually open a ticket, see How to contact Yellax support.

The short version

In most cases, support needs five things:

What you were trying to do.
What happened instead.
When it happened.
Which data is affected (project, dataset, object).
Which users are affected.

If you include those five, you are already ahead of most tickets. The rest of this article explains each one, plus a few extras that help in specific situations.

What to include

1. What you were trying to do

One or two sentences describing the goal, not the steps. "I was promoting validated data from a working dataset to the main dataset" is more useful than "I clicked the green button". The goal lets support understand which feature you were using and what the expected outcome should be.

2. What happened instead

Describe the actual result, with the exact error message if there was one. A screenshot of the error is more reliable than a paraphrase, since error messages often contain identifiers that help us trace the issue.

If there was no error, describe what you saw instead: a missing record, a wrong value, an empty list, a page that did not load.

3. When it happened

The approximate date and time, including timezone if you are outside the Netherlands. This matters more than people expect:

The platform's audit history is time-based, so we look up changes by timestamp.
Backup retention windows are time-based, so support can tell you immediately whether recovery is even possible.
If multiple users in your tenant report similar issues, timing helps us correlate them into one incident.

"Yesterday afternoon" is workable. "Around 14:30 on Tuesday 26 May, CET" is much better.

4. Which data is affected

Name the project, dataset, or specific object that is affected. A URL is even better, since it points support directly at the right place. If multiple items are affected, list them, or describe the pattern ("all records imported from the May batch", "every object with status 'in review'").

5. Which users are affected

Just you? A specific colleague? Everyone in your tenant? This distinction shapes how support investigates:

One user only: more likely to be a permission, browser or local setup issue.
A specific group: more likely to be a role or dataset-scope issue.
All users in your tenant: more likely to be a tenant-level issue or a service incident.

Helpful extras

What you have already tried

If you tried to resolve the issue yourself, mention what you tried and what happened. This prevents support from suggesting the same steps and shows where to start.

Common ones to mention:

Refreshing the page or logging out and back in.
Trying a different browser.
Asking a colleague to reproduce the issue.
Checking version control or audit history.

Screenshots and screen recordings

A screenshot is worth a paragraph. A short screen recording is worth a long ticket exchange, especially for:

Issues that are hard to describe in words.
Intermittent issues that only appear under specific conditions.
Anything involving timing or interaction (clicks, drags, keyboard input).

Most operating systems include a built-in screen recorder. Keep recordings short (under a minute is usually plenty) and crop or blur anything sensitive before attaching.

Browser and operating system

For issues that look visual or interaction-related (layout broken, button does not respond, file upload fails), mention which browser and operating system you are using. Most other issues do not need this.

Whether the issue is blocking

A short note on impact helps support prioritise. Useful framings:

"Blocking, cannot continue our work."
"Workaround in place, but slowing us down."
"Annoying but not urgent."

Be honest. Tickets marked blocking that turn out not to be slow down the genuine incidents.

What not to include

A few things to leave out:

Passwords or access tokens. Never put credentials in a ticket. If support needs to reproduce something, we will arrange it through a safer channel.
Long quoted error stacks without context. A screenshot or short excerpt is more useful than a thousand-line log. If support needs the full log, we will ask.
Multiple unrelated issues in one ticket. Open one ticket per issue. It keeps the history clean and prevents one slow issue from blocking the others.

Templates

For convenience, two short templates you can copy into a ticket.

General issue template

  What I was trying to do: 
  What happened instead: 
  When (date, time, timezone): 
  Affected project / dataset / object: 
  Affected users: 
  What I have already tried: 
  Impact: 
  Attachments: [screenshot / recording]

Feature request template

For situations where you would like to suggest a new feature, an improvement to an existing feature, or a change in platform behaviour.

Feature requests are reviewed during product planning. You will get a confirmation that we received your request, but a decision on whether and when to implement it may take longer, and not every request results in a change. Even so, well-described requests are valuable input into how the platform evolves.

  What you would like to do: 
  Why this matters to your work: 
  How you handle it today (workaround, if any): 
  Who would benefit (just you, your team, your whole tenant, likely other customers too): 
  How often this comes up: 
  Examples or references (screenshots, links, comparable behaviour elsewhere): 
  Priority for your work (nice to have / important / blocking):

The feature request template focuses on the underlying need rather than a specific solution. Describing the goal and the impact lets Yellax weigh the request against the roadmap and find the best way to address it, which is not always the solution you had in mind. References and examples are welcome but optional.