Boards — the kanban primitive behind tickets, bugs, and feature requests

Updated May 22, 2026

A board is a kanban-style workspace where every incoming ticket — whether from a form submission, a bug report, or a feature request — is organised into columns that represent its current status. If you've used Trello, Jira, or Linear, boards will feel familiar.

Where your boards live

There is no page that lists your boards. Every board you can see is a row in the sidebar under Communications → Tickets, named after the board and carrying its own unread badge. Click a row to open the board; typing the bare address /dashboard/tickets lands you on the first board you can see. If you cannot see any board at all, the Tickets group is not in your sidebar — that is an access question, not a missing feature.

Which boards you see is decided board by board. An admin grants it at Settings → Organization settings → Organization, by expanding a member and ticking boards under Board access. Only the organisation owner sees every board automatically — an administrator does not.

You start with two, created when you signed up: a bug board and a feature request board. In an English account they are called Bugs and Feature Requests; in a Hungarian one, Hibák and Funkciókérések. Each already has a submission form.

To make a new one, click + New board — the last row of that Tickets list. It creates a board of type Custom with a single column called New, and drops you straight onto its Settings tab so you can rename it and set its type. You need the Board management right to see that button. A board you create starts out visible to you alone. Grant your colleagues access under Board access before expecting them to find it.

One board, three tabs

A board is one place with three tabs, each its own bookmarkable address:

  • Tickets — the kanban itself.
  • Forms — the intake forms that create tickets on this board.
  • Settings — the board's name, its type, and the danger zone.

Which tabs you see depends on what you've been granted. The Forms tab only appears if you hold the Forms right, and Settings only if you hold Board management. A teammate with plain Tickets access sees the kanban and nothing else.

Board types

A board is one of three types, chosen on its Settings tab:

  • Bug — For incoming bug reports. Bug reports submitted through the widget land here automatically when this board is linked to your bug reporting flow.
  • Feature Request — Powers the public roadmap and in-widget voting. Visitors can submit ideas, upvote existing requests, and watch their status change.
  • Custom — For anything else: support requests, contact forms, job applications, internal task queues. You define the columns and forms.

Columns

Each board has columns. You create and name them however you like — "New", "In progress", "Fixed", "Won't fix" — and drag tickets between them as work progresses. There is a generous ceiling on how many one board can hold — far more than a working process needs — and it can be raised on request. A column has:

  • Name — displayed on the board and in ticket detail.
  • Color — accent color for visual grouping.
  • Public / Private — public columns are visible to visitors on the public roadmap and in the widget's roadmap tab; private columns are team-only. This toggle only matters for Feature Request boards.

The first column is the default one: new submissions land in it, and it cannot be deleted, moved, or made public. On the bug board Yaplet created for you at signup, the last column is flagged as a default too, so it cannot be deleted or made public either.

Labels

Columns tell you what stage a ticket is at. Labels tell you what it's about — short coloured tags you put on tickets to group them across columns. A ticket sitting in "In progress" can be tagged billing and mobile at the same time.

Each board has its own set of labels. To manage them, open a board, click the two-arrow export, import and labels button in the toolbar, and choose Labels… — from there you can add, rename, recolour, and delete them. To put labels on a ticket, open it and pick them in the details panel; they show up as coloured chips on the ticket's card.

You can also filter a board by label, from the Filters button above the columns. Pick more than one and you'll only see tickets carrying every label you picked, not any of them.

A few things worth knowing:

  • Labels belong to a single board — two boards don't share them.
  • A board can hold a generous number of labels — more than a team normally needs, and raisable on request.
  • The ten colours match Trello's, so labels survive a move between Trello and Yaplet in either direction.
  • Deleting a label removes it from every ticket that was using it.

Tickets

Every item on a board is a ticket. A ticket records:

  • A title and short summary — written automatically for widget submissions, with email addresses, phone numbers, links and @handles stripped out before anything is generated, and editable anytime
  • The form data submitted by the user (shown as a structured response)
  • The visitor who submitted it, with a link through to their conversation
  • Assigned agent and priority (Low / Medium / High)
  • For bug reports: screenshot, session replay, console logs, network logs, device metadata
  • For feature requests: the upvotes visitors have cast — the count is shown on your public roadmap and in exports, not on the kanban card
  • Internal comments from your team

Creating, editing, moving and deleting tickets all happen on the server, so a colleague with the same board open sees your change immediately and the mobile app stays in step. Ticket deletions are written to your audit log. All of it needs the Tickets permission — being signed in is no longer enough.

An organisation can hold up to 50,000 tickets in total. That is an anti-abuse ceiling rather than a working limit; if you have a legitimate reason to go past it, ask support.

Forms on boards

Each board can have one or more forms attached to it, listed on its Forms tab. When a visitor submits a form, a ticket is created in the board's default column with the form data embedded. You can filter the ticket list by which form created each ticket — useful when one board handles multiple intake points.

Deleting a board

Deleting is in the danger zone at the bottom of the board's Settings tab. The confirmation counts what it will destroy in real numbers — for example "This permanently deletes 42 tickets and the 2 intake forms that feed this board" — warns you that anyone using those forms in a widget will stop being able to submit, and refuses to proceed until you type the board's name exactly.

The two boards Yaplet created for you at signup are marked as your defaults and cannot be deleted at all. The delete button is greyed out on them and says so. Boards you made yourself can go.

One thing to expect afterwards: colleagues who had the board open watch its tickets vanish live, but the board itself stays in their sidebar until they reload the page.

Who uses boards

  • Support teams — triage incoming form submissions and bug reports.
  • Product teams — review feature requests and move them through the columns your public roadmap shows.
  • Developers — work the bug board, view session replays and console logs without leaving Yaplet.

Did this article answer your question?