# Working Tickets in the App

Use the Tickets area to triage incoming requests, collaborate with teammates,
reply to reporters, and track work through resolution.

## Find and organize tickets

The ticket list supports search, status, assignee, and label filters. Use the
quick filters for:

- **My unresolved**: open tickets assigned to you
- **My team's unresolved**: open tickets assigned to members of your People teams
- **Unassigned unresolved**: open tickets that still need an owner

Save frequently used search and filter combinations as presets. Saved presets
are available on your other devices.

Ticket rows show the status, priority, type, assignee, reporter, labels, age,
SLA warnings, and response or resolution times when available. New and updated
tickets appear automatically.

Starter and Pro users can switch between the ticket list and Kanban board.
Use **People** to group tickets by assignee and drag tickets between columns to
reassign them.

## Review ticket analytics

Pro users with permission to manage project tickets can open **Insights** to
review:

- Backlog, created, closed, and reopened tickets
- SLA risk, breaches, and compliance
- Median first-response and resolution times
- Daily trends and breakdowns by status, priority, type, customer, assignee,
  and age

Choose a preset or custom date range, compare it with another period, and
filter by assignee, customer, type, or priority. Active filters stay visible and
can be removed individually or cleared together. Use **Saved views** for report
setups your team reviews regularly.

Select a metric, chart point, daily value, or breakdown to open matching tickets
in one reusable **Insights results** tab. Further selections update that tab
instead of creating duplicates. Opening a result uses the normal ticket tab,
while the report keeps its range, filters, scroll position, and chart state.
On desktop, tabs can be dragged into a split view to keep the report and results
side by side. You can also compare two assignees, customers, priorities, or
ticket types in the same period.

Use annotations to explain incidents, staffing changes, SLA adjustments, or
workflow changes on trend charts. **Copy report link** shares the selected
range, comparison, filters, and section. **Export** creates CSV, PNG, or PDF
reports; image and PDF exports use your workspace branding.

Open **Methodology** for metric definitions, data coverage, timezone, and
freshness. Today may be partial. Insights starts collecting history when the
project is activated and does not backfill earlier activity. If a report needs
more data, Bnder explains what is missing and suggests clearing filters or
trying another range.

## Create a ticket

Enter the ticket's title and any required fields, then select **Create ticket**.
Missing required fields are marked directly in the form.

Depending on project settings, you can set:

- Description, type, priority, and status
- Assignee and SLA
- Customer and reporter details
- Additional notification email addresses
- Labels and template fields

Ticket types and required template fields come from project settings. Untouched
projects use **General** by default; configured projects follow their selected
default or require you to choose a type.

## Work in ticket detail

Open a ticket row to view and update the complete ticket. Existing-ticket
changes save automatically; the header shows whether changes are saving, saved,
or failed. Updates made by other agents appear automatically.

Use **Assign to me** to take ownership quickly. If your workspace uses virtual
coworkers for Customer Support, eligible coworkers also appear in the assignee
list.

Customer-linked tickets can show customer details, related tickets, portal
visibility, and a public portal link.

## Replies and internal notes

Use **Public reply** when the reporter should receive the message by email or
see it in the customer portal. Use **Internal note** for information that should
remain visible only to workspace members.

You can mention workspace users with `@username`. Mention and assignment
notifications follow the recipient's workspace notification channel and
settings.

Public replies and internal notes can include attachments. Workspace file-type,
size, storage, and malware-scanning limits apply. Files that were not scanned
successfully cannot be opened by public users; workspace admins can retry a
failed scan.

## Link related work

The **Linked Resources** section connects a ticket to tasks and knowledge
documents. Start typing to search, then select a result. You can also create a
new linked task directly from the ticket.

Use **Child Tickets**, **Duplicates**, and **Related Tickets** for
ticket-to-ticket relationships. For incident and duplicate workflows, see
[Master Tickets](https://bnder.net/help/tickets/master-tickets).

When a resolved or rejected ticket contains reusable knowledge, Pro workspaces
can use **Create knowledge draft**. Bnder opens a structured document draft and
links the saved document back to the ticket.

## Activity

The **Activity** section records who changed a ticket, when it changed, and the
visible before-and-after values.

## Automatic status changes

Depending on project configuration:

- A reporter reply can reopen a resolved ticket.
- An agent's public reply can move the ticket to **Waiting on reporter**.
- A reporter reply can move a waiting ticket back to the configured
  in-progress status.
- The assigned agent is notified when the reporter sends a new public message.
- A newly assigned agent is notified, except when assigning the ticket to
  yourself.
- Completing the final open task linked to a ticket can offer to resolve the
  ticket.

SLA warnings depend on the ticket age and the project's SLA settings.

## New-ticket alerts

Project admins can enable new-ticket alerts per member under
**Project Settings → Members**. Notifications use Slack DM, Discord DM, or email
according to the workspace type. People are not notified about tickets they
created themselves.

## Discord ticket workflow

The **Ticket Manager** Discord bot supports creating and working with tickets
directly in Discord:

:md-ticket-commands

Reporter commands are available to regular users. Agent commands require the
project's `MANAGE_TICKETS` permission.

If a ticket type requires template fields, Discord opens a form for supported
fields. Required file fields must be completed through the public ticket page.
Replies to Discord-created tickets direct the reporter to the public ticket
thread.


# Ticket Email Routing

Ticket emails support notification delivery, inbox routing, and reply-based workflows.

Public ticket forms are available without Pro. :br
Email routing and reply-by-email require at least one **Pro seat** in the workspace.
Customer-owned ticket mailboxes also require Pro seats and scale with your Pro seats: one hosted mailbox per Pro seat.

## Outbound notifications

Ticket emails are sent for key events such as:

- New ticket created
- New public message
- Ticket moved into closed states (for example resolved/rejected)
- Ticket auto-closed after waiting on reporter timeout
- SLA warning became active

For update mails with a new public message, the message content is rendered in a dedicated message box for better readability.

Recipients are derived from reporter + notify emails, excluding:

- Unsubscribed addresses
- The actor address that triggered the event

## Branding and footer

Ticket emails use the logo, display name, and primary color from the Pages domain used for public ticket links.
If that branding is not configured, the email falls back to the Bnder logo and default accent color.

When a Pages display name is available, the footer includes a sender context line such as "Sent for your workspace via Bnder.", with the Bnder label linked to bnder.net. It also keeps the Bnder legal company details and legal links.

In **Project Settings -> Tickets -> Ticket links and branding**, select the Pages domain for each project. This controls new thread and unsubscribe links plus the logo, display name, and primary color in notification emails. Multiple projects can intentionally share one domain.

The selection is captured when a ticket is created. Existing ticket links keep their original domain after you change the project setting. Tickets created directly from a public Pages form keep the domain on which the form was opened. If no project domain is selected, Bnder shows and uses the workspace default.

## Reply-To behavior

Ticket emails first use the project **Customer mailbox** when one is connected and the workspace has Pro seats.

Examples:

- `support@your-company.com`
- `helpdesk@customer.com`

When a customer mailbox is active, participant/reporter ticket emails are sent from that address and replies go back to the same inbox.

If no customer mailbox is connected, Ticket emails set Reply-To per project to the configured Bnder fallback mailbox local-part:

- `<your-project-local-part>@tickets.bnder.net`

If no project mailbox is configured yet, the system falls back to the default inbox address.

Replies can be routed automatically from these inboxes into ticket updates with **Pro** seats.

## Sender behavior

Ticket emails use the connected customer mailbox as sender when possible. If outbound sending from that provider fails or is not configured, they fall back to the project Bnder address:

- `<your-project-local-part>@tickets.bnder.net`

If no mailbox local-part is configured yet, the system generates one from the workspace and project names, stores it in the project ticket settings, and reuses it for future replies until a user changes it manually.

## Customer mailbox setup

In **Project Settings -> Tickets**, use **Customer mailbox** to:

- Configure standards-compatible SMTP/IMAP mailboxes in the inline setup form
- Select any active project and bind an unassigned mailbox without leaving the mailbox card
- Review and confirm which existing mailbox will stop receiving mail before replacing a project's assignment
- Confirm before disconnecting a mailbox; inbound sync pauses and the project returns to its Bnder fallback address
- See the affected mailbox and project in the success message after connecting, replacing, or disconnecting
- Retry project loading directly from the mailbox card if assignment options are temporarily unavailable
- See when an unassigned mailbox has paused inbound sync, including its last successful sync and latest error
- Enable or disable inbound sync and outbound sending separately
- Replace SMTP/IMAP credentials when they rotate
- Delete mailbox connections that should no longer be used
- Test the connection and view separate receiving and sending health
- Recover inbound emails that repeatedly failed processing from **Workspace health** or the mailbox settings: retry them, download the original `.eml`, or dismiss them after review

Use **Ticket links and branding** on the same page to pair this project's mailbox workflow with the correct customer-facing domain. The mailbox decides where mail is sent from and where replies arrive; the Pages domain independently decides which links and visual branding appear inside those emails.

Use shared team addresses, not personal agent mailboxes.
Each Pro seat adds one customer mailbox slot. If the workspace reaches the limit, add another Pro seat or remove an unused mailbox connection.
For Microsoft 365 or Google Workspace, use SMTP/IMAP settings if your workspace admin allows those protocols.
For v1, one inbound-enabled mailbox should be bound to one project so new-ticket routing stays unambiguous.

SMTP/IMAP credentials are stored server-side only and are never shown again in the app. You can still change mailbox labels or enable/disable inbound and outbound handling without re-entering credentials.
When you connect a mailbox, Bnder starts with new messages rather than importing older mail.
If an inbound email cannot be converted into a ticket after three attempts, Bnder keeps it in the mailbox recovery panel instead of discarding it. **Retry** processes the saved message again, **Download email** saves the original message for inspection, and **Dismiss** permanently removes it after confirmation.
Deleting a project releases its Bnder fallback address and unassigns its customer mailbox. The mailbox connection and credentials remain available in workspace settings so you can connect them to another project or delete them explicitly.
Very large inbound attachments may be omitted from a ticket reply if they would exceed the internal email processing limit. The ticket message will include a note when that happens.
Inbound email attachments are stored as ticket conversation attachments when public/customer uploads are enabled for ticket settings.
They are ignored before storage if adding them would exceed the ticket's combined attachment-size limit.
They are also ignored before storage if the workspace only allows selected upload file types and the attachment MIME type is not allowed.
They are not forwarded back out as email attachments; recipients open the ticket thread to preview or download files.
If public/customer uploads are disabled, Bnder still accepts the inbound message text but ignores the inbound files.
If closed-ticket attachment cleanup is enabled, stored inbound attachments are removed with the rest of the ticket's attachments after the retention period.

## Subject format and ticket matching

Notification subjects include a ticket marker:

- Example pattern: `[Ticket <ticket-id>]`

If a mail app rewrites the subject and removes the marker, Bnder can still match replies from standard email thread headers such as `In-Reply-To` and `References` when the original Bnder ticket email is still part of the mail thread.

## Inbound create vs reply behavior

When an inbound provider forwards an email:

- If subject contains an explicit ticket marker, it is handled as a reply
- If the subject marker is missing but the mail thread points to a Bnder ticket email, it is handled as a reply
- If not, it can create a new ticket when Pro email routing is available
- New inbound tickets are routed by the connected customer mailbox or, for fallback routing, recipient mailbox local-part (`<local-part>@tickets.bnder.net`)
- Customer mapping is optional and used to auto-assign customer + SLA; if a mapped customer has a default project, that project is preferred for creation
- On successful inbound ticket creation, CC recipients are added to the ticket notify list
- The ticket-created confirmation sent to the sender is threaded as a reply to the inbound mail (when message id is available)
- If reply-by-email is not available because the workspace has no Pro seat, inbound reply emails are ignored and the sender receives a guidance email

### Recipient requirements for new inbound tickets

The inbox local-part must exist for the target project. It can be set manually in the ticket settings or generated automatically the first time the project sends a reply-capable ticket email.

If the local-part is unknown, no ticket is created and the sender receives a dedicated guidance email.
When the inbound mail contains a message id, this guidance email is sent as a thread reply in the sender mailbox.

## Common inbound errors

- **Unknown ticket mailbox local-part**:br
  No ticket is created. The sender receives a guidance email. :br
  Configure the project inbox local-part in **Project Settings -> Tickets** or send one replyable ticket email first so the system can generate and persist a dedicated route automatically.


# Ticket FAQ

## Why do ticket settings save without a Save button?

Workspace and project ticket settings save automatically. The save status shows
whether the latest change succeeded.

## Why can I not change a template on an existing ticket?

Templates are fixed after creation so required fields and historical data remain
consistent.

## Why can I not create a knowledge draft?

**Create knowledge draft** appears only for resolved or rejected tickets. You
also need permission to manage documents in the project and a Pro seat in the
workspace.

## Why is a template field read-only?

Project admins can make a field visible but not user-editable. This is useful
for defaults or values controlled by the support team.

## Why is a project missing from public ticket creation?

Check that:

1. Public tickets are enabled under **Project Settings → Tickets**.
2. You opened the correct workspace Pages domain.
3. A customer intake link belongs to the same project and is still valid.

## Why did a resolved ticket reopen?

A new public reply from the reporter reopens a resolved or rejected ticket.

## Why did the ticket move to Waiting on reporter?

An agent's public reply can move the ticket to the configured waiting status.
The reporter's next reply moves it back to the configured in-progress status.

## Why can reporters not choose priority?

Priority is controlled by the support team so triage stays consistent.

## Why did someone not receive a notification?

Bnder skips self-notifications. Also check the recipient's personal direct
notification setting and, for new-ticket alerts, their setting under
**Project Settings → Members**.

Reporter notifications follow the original channel: Discord reporters receive
a Discord DM, while email and public-form reporters receive email.

## What happens when a public form fails validation?

The form keeps the entered data and shows errors beside the affected fields.
The create action remains unavailable until required fields and character
limits are valid.

## What if the ticket is created but an attachment fails?

Do not submit the creation form again. Open the created ticket from the
partial-success message and upload the file again from its thread.

## Why can I not open an attachment?

The file may have been removed, blocked by workspace file-type rules, exceeded a
size or storage limit, or still be waiting for malware scanning. Public users
cannot open files that failed or skipped scanning; an admin can retry the scan.

## What happens if I refresh a public ticket form?

Bnder restores the draft for that page from the current browser session.

## Where can I see ticket changes?

Open **Activity** in ticket detail to see when a change happened, who made it,
and the visible before-and-after values. The timeline can also be exported for
audit work.

## Can reporters reply by email?

Yes, when email routing is configured in a Pro workspace. Ticket email uses a
reply address associated with the correct project and ticket.

See [Ticket Email Routing](https://bnder.net/help/tickets/email-routing).

## Why was no ticket created from an inbound email?

Check the recipient address in **Project Settings → Tickets**. For connected
mailboxes, review **Inbound messages need attention** for failed messages and
retry after correcting the mailbox or message issue.

Repeated delivery of the same email does not create duplicate tickets or
replies.

## Why can I not save a customer?

Customer names are required, email addresses must be valid and unique, and a
selected SLA must still exist. Customer capacity and customer-specific SLAs
also depend on available Pro seats.

## What happens when an SLA is deleted?

Tickets stop using that SLA and its active warning state is removed.

## Do SLA timers include holidays?

Not currently. SLA business hours support timezone, weekdays, and start/end
hours.

## Where are save and action errors shown?

Ticket detail keeps save status and other action notices near the top of the
page. Fix the issue and retry the affected action; do not repeat a successful
ticket creation or message send.

## How long are ticket email links valid?

Reply and unsubscribe links in ticket email are valid for 90 days.

## Where are customer intake links configured?

Create customers in **Workspace Settings → Tickets**. Generate the
project-specific customer links from **Project Settings → Tickets**.


# Ticket System Overview

The ticket system helps teams handle support requests from inside the app and from public pages.

For a product-level overview of how tickets connect with tasks and public knowledge, see the public tickets page at [`/tickets`](https://bnder.net/tickets).

## What the ticket system includes

- A ticket list with filters, labels, SLA warning chips, and live updates
- A ticket detail view with conversation, links, attachments, and custom template fields
- Immutable ticket audit timeline in the ticket detail **Activity** section, plus CSV export for compliance/reporting
- Workspace and project ticket settings (statuses, SLA, customers, templates)
- Multi-step SLA targets (first response, next response, resolution) with warning + breach handling
- Public ticket creation and public ticket thread pages on your Bnder page domain
- Email notifications with unsubscribe links

## Pro-only ticket features

The following ticket capabilities require at least one Pro seat in the workspace:

- SLA policies (SLA definitions, default SLA, SLA warning automation)
- SLA breach escalation to configured workspace members
- Multiple customers and customer-specific SLA assignments
- Reply-by-email routing

## Workspace vs project settings

- **Workspace Ticket Settings**:br
  Manage shared customer profiles and customer-specific intake links.
- **Project Settings -> Tickets**:br
  Configure public intake toggle, public links, statuses, SLAs, enforced templates, and template definitions.

## Permissions

To manage tickets in the app, users need the `MANAGE_TICKETS` permission. :br
See [Permissions](https://bnder.net/help/permissions).

## Quick start

1. Configure ticket settings and public intake: [Ticket Setup](https://bnder.net/help/tickets/setup)
2. Train agents on day-to-day usage: [Working Tickets in the App](https://bnder.net/help/tickets/agent-workflow)
3. Coordinate incidents and duplicates: [Master Tickets](https://bnder.net/help/tickets/master-tickets)
4. Share public ticket links: [Public Ticket Portal](https://bnder.net/help/tickets/public-portal)
5. Set up email reply routing: [Ticket Email Routing](https://bnder.net/help/tickets/email-routing)
6. Check common edge cases: [Ticket FAQ](https://bnder.net/help/tickets/faq)
7. Use Discord command reference: [Discord Commands -> Ticket Commands](https://bnder.net/help/integrations/discord/all-commands#ticket-commands)


# Master Tickets

This guide explains **master tickets** from an agent/user perspective.

Master tickets help you coordinate one larger issue (for example an outage, recurring bug, or shared incident) while keeping customer conversations separated in child tickets.

## When to use a master ticket

Use a master ticket when:

- Multiple customers report the same problem
- You want one internal coordination ticket for a broader incident
- One issue creates several follow-up tickets
- You need to track progress across related tickets in one place

## Core idea

- **Master ticket**: the parent ticket used for coordination and rollups
- **Child tickets**: customer-facing or follow-up tickets linked to the master
- **Relationship types**: links describe why tickets are connected (for example duplicate, child, related)

This keeps customer communication isolated while agents still get one operational view.

## What agents see on a master ticket

The master ticket workflow area shows a rollup summary of linked child tickets, including:

- Child ticket counts by status
- Open vs closed child counts
- SLA warning count across child tickets
- Latest customer reply across child tickets
- Affected customers and projects summary

This helps agents prioritize and decide whether to broadcast updates or close child tickets in bulk.

## Typical workflow (incident / duplicate handling)

1. Create a normal ticket or open an existing shared-issue ticket
2. Use **Convert to Master Ticket** to make the role explicit
3. Add child tickets or link duplicates from the dedicated master actions
4. Work investigation and internal coordination in the master ticket
5. Keep customer-specific replies inside each child ticket
6. Use bulk actions from the master ticket when the issue is resolved

## Creating a master ticket in the app

The app supports two explicit ways to start a master ticket workflow:

- Enable **Create as master ticket** while creating a new ticket
- Open an existing ticket and click **Convert to Master Ticket**

After conversion/creation, the app immediately opens the child-ticket linking flow so the ticket does not remain an empty implicit master by accident.

## Relationship sections in ticket detail

Master-ticket detail separates relationship types into dedicated sections:

- **Child Tickets**
- **Duplicates**
- **Related Tickets**
- **Linked Resources** for tasks and knowledge documents

This makes it obvious which links drive master workflows and which links are only supporting references.

## Master actions available

From the master ticket, agents can run bulk actions on child tickets:

- Bulk update child status
- Bulk assign child tickets
- Bulk update child labels
- Bulk close child tickets
- Broadcast a message to selected child tickets

Bulk actions can target:

- All child tickets
- A selected subset of child tickets

## Customer-safe communication model

Master tickets are designed for safe coordination across multiple customers.

- The master ticket can be used as an internal coordination layer
- Child tickets remain customer-facing
- Public updates are sent to each selected child ticket separately
- Customer details are not shared across other child tickets

Important: do not use a child ticket to communicate incident details meant for all affected customers. Use the master ticket broadcast action so each customer receives an isolated update in their own thread.

## Sync behavior (what can be automated)

Workspaces can configure master/child sync policies so common updates stay consistent.

Relationship changes and bulk child updates are saved as one operation. If another agent changes one of the same tickets
at the same time, Bnder asks you to reload and retry instead of saving a partial or contradictory relationship.
One bulk update or close action can change up to 100 child tickets at once. Select a smaller group when a master ticket
has more children; Bnder rejects an oversized action before changing any ticket.

Examples:

- Sync master status to child tickets
- Sync assignee, labels, or priority from master to child tickets
- Reopen the master ticket when a reporter replies on a child ticket
- Escalate the master ticket based on child ticket urgency/SLA risk

These sync rules are configurable and can be enabled per field.

## Best practices

- Use the master ticket title for the shared problem, not one specific customer
- Keep customer-specific troubleshooting in child tickets
- Use internal notes/messages on the master ticket for coordination
- Use broadcasts for customer-facing updates across many child tickets
- Close child tickets in bulk only after confirming the shared issue is resolved for all selected customers

## Example scenario

Example: Login outage reported by 8 customers

- Create master ticket: `Login failures after deployment`
- Link 8 customer tickets as child tickets
- Track investigation, rollback, and root-cause notes in the master ticket
- Send a public update broadcast to all 8 child tickets
- After fix verification, bulk-close child tickets as solved

## Related guides

- [Working Tickets in the App](https://bnder.net/help/tickets/agent-workflow)
- [Ticket FAQ](https://bnder.net/help/tickets/faq)


# Public Ticket Portal

The public portal lets customers create and reply to tickets from your Bnder
Pages domain.

## Public links

Common public paths include:

- Create a project ticket: `/ticket/{project_id}`
- Open a ticket thread: `/ticket/thread/{token}`
- View customer tickets: `/tickets`
- Request customer login: `/tickets/login`
- Unsubscribe: `/ticket/unsubscribe/{token}`

A domain's **landing project** controls where visitors go when the URL does not
already name a project. A project's **branding domain** controls the domain used
in generated ticket links and emails. Configure both in Pages and ticket
settings.

Custom domains become available after DNS ownership and SSL checks succeed.
Existing ticket links keep the domain selected when the ticket was created, so
review old links before deleting a domain.

## Create a ticket

Depending on project settings, the public form can include:

- Reporter email and name
- Workspace sign-in with Discord or Slack
- Title, description, type, and initial message
- Template fields
- Attachments
- Related public knowledge suggestions

Workspace admins can allow anonymous creation or require customer login. When
customer portal login is enabled, visitors also see **My Tickets**.

Ticket-type templates take precedence over the project-wide template. Only
fields intended for reporters are shown. Required fields are validated before
the ticket is created.

A project-specific customer link can preselect a customer. Public creation adds
only the reporter as a notification recipient.

## Reporter sign-in

Email is always available. Discord-backed workspaces can additionally offer
Discord sign-in, while Slack-native workspaces can offer Slack sign-in.

Workspace sign-in uses a popup and does not require an existing Bnder app
account. If the sign-in expires before submission, sign in again.

## Knowledge suggestions

When enabled, related public documents appear while the reporter enters the
ticket. Suggested documents open separately so the unfinished form remains
available.

## Attachments

Public forms and ticket threads support file selection and drag and drop.
Workspace file-type, per-ticket size, storage, and malware-scanning limits
apply.

Files waiting for a scan remain unavailable. Malware and failed scans block
public access; workspace admins can retry failed scans. Admins can also
configure cleanup of attachments from closed tickets.

## Ticket threads

A thread link lets its recipient:

- Read the public conversation
- Reply to the support team
- Add and open public attachments
- Create another ticket

New public messages appear automatically while the page remains open. Internal
notes, agent-only attachments, labels, priorities, assignees, and linked
workspace items are never shown.

Each recipient receives an individual secure thread link. Do not forward it to
someone who should not have access to the conversation.

Admins can disable public replies or uploads. Existing links remain readable
and clearly show when an action is unavailable.

A new reporter reply reopens a resolved or rejected ticket.

## Customer portal

When customer login is enabled, customers can request a sign-in link by email.
The confirmation page does not reveal whether an email address belongs to a
known customer.

Signed-in customers can:

- View their own current and older tickets
- Open a ticket and reply
- Upload attachments when allowed
- Create another ticket without re-entering contact details
- Log out from the device

## Unsubscribe

Ticket emails include an unsubscribe link. Opening it updates that recipient's
notification preference. Invalid or expired links show an error and retry
option.

For setup, see [Ticket Setup](https://bnder.net/help/tickets/setup). For domain configuration,
see [Pages](https://bnder.net/help/pages).


# Ticket Setup

Use this guide to prepare a project for customer support.

## 1. Grant access

Agents need the **Manage tickets** permission in the project. Without it, they
cannot open or manage the ticket area.

See [Permissions](https://bnder.net/help/permissions).

## 2. Open ticket settings

Go to **Project Settings → Tickets**. Project settings control:

- Public ticket intake
- Email intake and customer mailbox
- Statuses and ticket types
- SLAs
- Waiting-on-reporter auto-close timing
- Templates and required fields

Changes save automatically.

## 3. Enable public ticket intake

Enable **Public tickets** when external users should create tickets from your
Bnder Pages domain. The settings page shows the public links for each configured
domain.

If no domain exists yet, configure one in **Workspace Settings → Pages**.
See [Pages](https://bnder.net/help/pages) and
[Public Ticket Portal](https://bnder.net/help/tickets/public-portal).

## 4. Configure email routing

::md-hint-box{type="info"}
Email intake and reply-by-email require Pro.
::

You can either connect a shared customer mailbox with SMTP/IMAP or use a Bnder
fallback address such as `support@tickets.bnder.net` as shown in your
project settings.

Use a shared support mailbox rather than a personal agent mailbox. Test inbound
and outbound mail separately before publishing the address.

See [Ticket Email Routing](https://bnder.net/help/tickets/email-routing).

## 5. Add customers

Go to **Workspace Settings → Tickets** to create customer profiles. A customer
can include:

- Name and company
- Email addresses and phone numbers
- Customer-specific SLA
- Metadata for reporting and segmentation

Customer email addresses must be unique. Customer links can preselect a
customer on a project-specific intake form.

Available privacy actions include:

- **Deactivate** to block portal login while keeping history
- **Reactivate** to restore login
- **Anonymize** to remove identifying profile details while retaining useful
  ticket history
- **Delete** to remove the reusable customer profile

Customer capacity depends on Pro seats. The settings page shows the current
limit.

## 6. Define statuses

Create the statuses agents use to move tickets through the workflow. Each
status belongs to a category, which determines whether Bnder treats the ticket
as open, waiting, resolved, or rejected.

## 7. Define SLAs

SLAs require Pro. An SLA can include:

- Resolution target
- First-response and next-response targets
- Warning threshold
- Business hours and timezone
- Members notified when a breach occurs

Set a default SLA when most tickets should use the same policy. Customer and
project business-hour overrides take precedence over the SLA default.

Holiday calendars are not currently included in SLA timer calculations.

## 8. Configure ticket types and templates

Define the types available in the project and select a default type. Untouched
projects use **General**. Choosing no default requires agents and reporters to
select a type.

Templates can contain text, multiline text, number, email, date, file, and
boolean fields. Fields can be required, visible, editable, or prefilled.

You can enforce one template for the project or bind different templates to
individual ticket types. Type-specific templates take precedence.

Discord ticket creation supports required form fields except required file
fields. Reporters must use the public ticket form when a required file field is
present.

## 9. Configure notifications

Under **Project Settings → Members**, enable **New ticket notifications** for
members who should be alerted. Notifications use Slack DM, Discord DM, or email
according to workspace type and personal settings. Ticket creators do not
receive a notification for their own ticket.

## 10. Optional automation

For virtual coworker support:

1. Choose the **Customer Support** department.
2. Include the ticket project in the coworker's project scope.
3. Grant **Write** permission if it should update tickets or reply.
4. Assign a ticket to the coworker when it should take ownership.

Assessment and handoff notes stay internal.

People routing policies can assign new unassigned tickets and react to SLA
warnings or breaches. See
[Ticket Routing with People](https://bnder.net/help/organization/ticket-routing).

## 11. Test the setup

Before inviting customers:

1. Create a ticket in the app.
2. Create one through the public project link.
3. Send a test email to the project inbox if email routing is enabled.
4. Confirm statuses, SLAs, types, and required template fields.
5. Reply from the public ticket thread.
6. Confirm the intended project members receive notifications.
7. Preview and test any routing or virtual coworker automation.

Next: [Working Tickets in the App](https://bnder.net/help/tickets/agent-workflow).


# June Changelog

## App

### General

- Improved onboarding experience
- Added templates for workspace creation
- You can now invite users via mail to your workspace that don't have a Bnder account yet
- You can now disable attachments on tickets from Bnder Pages
- Revamped webhooks
  - You can now configure multiple webhooks for the same project or global scope
  - You can configure the webhook format (Discord or technical)
  - Webhooks can have separate filters (object- or action-based)
  - Scales with paid seats
- Made it easy to see where workspace storage goes in workspace settings → Plans & Seats → Usage → Storage → More details
- You can disable each Smart Guard feature in the preferences
- Redesigned label settings
- “My day” view shows unresolved tickets
- Notifications can now be set on a project basis via project settings
- File uploads are now scanned for malware and viruses
- Added a new workspace monitor
  - See configuration issues
  - Manage malware findings
  - Security recommendations
- Made the usage section more structured on the Plans & Seats page
- Improved loading performance in many places
- Support for new languages
  - Arabic and United Arab Emirates
  - British English
  - Korean
  - Vietnamese
- Content of uploaded files (e.g. text in images or documents) can be found in workspace search

### Tasks

- Milestone create, update, and delete actions now use the project-scoped `MANAGE_MILESTONES` permission

### Tickets

- You will now get a notification and warning on a ticket if the reporter email can't be used to deliver mail
- Inbound mailbox sync ignores more mail types, such as disposition notifications and read notifications
- Moved “Add” buttons in ticket settings to the bottom of lists
- Switched from text fields to dropdowns in the ticket route preview
- Improved default escalation user selection
- Ticket conversation messages can have file attachments
- You can configure the attachment types for conversations in workspace settings
- You can configure the maximum attachment size for tickets in workspace settings
- You can save ticket filters for quick access

### Fixes

- Topic names in the topic list could overflow
- When uploading a workspace icon with incorrect dimensions, the error did not include the required dimensions
- Improved sync behavior on custom mailboxes for delivery failures
- Improved mail-to-ticket detection in inbound mail sync
- Possible error when reading file storage
- Wrong username was shown for a document author
- Multiple permission checks were tightened
- In workspace settings, the selected tab might not reflect the clicked tab
- Could not duplicate tasks inside projects with custom status columns
- Deleting a label did not remove the old stale label from tickets and documents
- Clicking a tab in workspace settings might not open the expected tab
- Some user data from deleted members was not deleted
- Event log could take unexpectedly long to load
- Setting only the hour in a task deadline would revert to midnight on save
- Webhook author could show a user ID instead of a username
- Custom brand logos in emails were too small
- Very long load times when opening workspace ticket settings

## Bnder Pages

- Users can now log in via mail to see all their tickets (if enabled in workspace settings)
- More pages have proper tab titles
- Entry point (public documents or new ticket) is now configurable
- Entry project is now configurable

### Fixes

- Custom branded icons were very small

## Discord Bots

### General

- Label names ignore emojis for better usability
- Support for more locales

### Fixes

- A permission mismatch between the app and bots was fixed. Bots no longer accept the Discord administrator permission
- Response to `/booking link` was not localized
- Error responses to `/people` commands didn't include a link to the pricing page