#Support Tickets

#Overview

The AiDial portal includes a support ticket workflow for questions, access issues, billing questions, and operational requests. Use it when you need AiDial or your delivery partner to review a portal issue with the right account context.

Support tickets are available to customer and partner portal users according to role. Your request is scoped to your signed-in organisation and, when relevant, to the selected client or project. The customer/partner Support page is authorised for client_admin, client_manager, client_staff, partner_admin, and partner_user; internal AiDial support actions are handled through the scoped support API/BFF routes where those routes allow them.

#When to Create a Ticket

Create a support ticket when you need help with:

• signing in, MFA, or access problems
• billing questions or invoice follow-up
• call history, dashboard, or reporting questions
• settings changes that are not available to your role
• project configuration questions that need partner or AiDial review
• a suspected incident or degraded portal experience

For urgent service-impacting issues, use your agreed escalation path as well as opening a ticket.

#Creating a Ticket

1. Sign in to the AiDial portal.
2. Open Support from the portal navigation.
3. Select New ticket.
4. Confirm the project the request belongs to.
5. Select Low, Normal, or High priority.
6. Add a short subject and complete What's happening?.
7. Optionally attach up to 5 recent calls from the same project.
8. Confirm who should receive ticket updates. You are always included, and you can add verified users from your organisation.
9. If you are a client administrator, optionally select PNG, JPG/JPEG, or PDF attachments when attachment storage is available.
10. Submit the ticket. If you selected attachments, the window stays open while they upload, then you close it.

Partner administrators and partner users create tickets from a form on their own ticket queue instead. That form asks for the request scope — your partner account, or an assigned client and one of its projects — plus a category, a priority from the full internal scale, a subject, and a description.

Do not include passwords, API keys, recovery codes, full payment details, or other secrets in a ticket. AiDial support will never ask you to paste one-time MFA codes or raw secret values.

#Starting a Ticket from Another Page

Some pages offer a support shortcut that opens the create form with context already filled in — for example the Billing pages, several Settings panels, and dashboard follow-up prompts. The link can prefill the subject, the description, the priority, and a related call reference. Everything stays editable before you submit, and prefilled values are still checked against your own project and tenant scope when the ticket is created.

#Related Calls

Customer users can attach recent call references while creating a ticket. The portal validates the selected calls before the ticket is submitted, deduplicates repeated references, and only allows calls that belong to the selected project and signed-in tenant scope. Changing the project on the create form clears any calls you already picked, because related calls are project-scoped.

The support BFF route contract also supports listing, attaching, and detaching related calls for scoped support workflows. Reverse lookup — finding which tickets are linked to a call reference — is a separate route, /api/calls/{callId}/related-tickets, that only AiDial administrators and operators can use; every other role gets the same not-found response. Those operations stay behind role, tenant, and project checks; the current ticket detail page only shows a linked-call shortcut when the ticket detail payload includes a safe related_call_id. Related-call validation and reverse ticket lookup do not expose caller details, transcripts, summaries, or tickets from another organisation.

#Update Recipients

The create form's Send updates to field accepts verified tenant users only. The portal stores user identifiers, not free-text email addresses, and displays recipient chips by display name. The signed-in user is added automatically and cannot be removed while creating the ticket.

A ticket must have at least 1 and at most 5 update recipients. Recipient add and remove actions are scoped to the ticket tenant, audited without raw email addresses, and protected by the same non-enumerating access checks as other support ticket actions.

#Uploads

Uploads let you add files to a project-scoped support ticket while preserving a safe display version of the filename you selected. The portal accepts png, jpg, jpeg, and pdf files up to 10 MB each, with up to 5 active attachments per ticket. Duplicate active filenames are rejected within the same ticket so that support can refer to each file unambiguously.

Uploaded files are private support-ticket data. Attachment storage is readiness-checked before the dropzone is enabled. When available, the portal requests a short-lived upload session from aidial_api; the browser uploads directly to DigitalOcean Spaces by pre-signed PUT URL, and the portal server does not receive the file bytes. Backend object keys use the support_attachments folder with server-generated file IDs; the user-selected filename is kept only as the safe display filename.

Files selected on the create form upload after the ticket has been created. The create window stays open, shows per-file progress, and offers a retry for any file that fails. Closing that window while files are still uploading asks you to confirm first. In ticket detail, a file can only be downloaded once its scan result is clean; a quarantined file is labelled as such and its download control stays disabled.

Attachment actions follow the API's per-action scope contract. Client administrators can upload, list, download, and remove scoped attachments. Client managers and client staff can list and download them but do not receive upload, finalise, or remove controls. AiDial administrators and operators can list, download, and remove only when an explicit target resolves through the managed-tenant API client; unmanaged targets receive the same not-found response before any attachment request is forwarded. Ticket detail omits attachment metadata until a client is selected. Partner administrators and partner users can still open tickets in their assigned-client scope, but ticket detail returns an empty attachment array and the portal renders no attachment heading or controls for those roles. The Portal records an authorization allow/deny event for each ticket-scoped attachment route before forwarding an allowed request.

#Ticket Categories

Customer-created tickets do not require a category at submission time, so a ticket can stay uncategorised until triage. Partner-created tickets always carry one, because the partner create form requires a category. Partner administrators, AiDial administrators, and AiDial operators set or change the category during triage, and a triage update will not save without one.

#Priority Guide

Choose the priority carefully. Overstating priority can slow triage because support may need extra clarification before acting. Low, Normal, and High are the customer choices, and Normal is stored as Medium internally. Partner and AiDial support roles work with the full internal scale — Critical, High, Medium, and Low — both when they create a ticket and during triage.

#Where Tickets Come From

Most tickets are created in the portal. A ticket can also be raised from a voice call, and ticket detail labels which origin it has. For a call-raised ticket, the detail page additionally shows the source project, the source channel, where the safe summary came from, and the safe summary itself. It does not show transcript content.

#Following Up

The Support page uses role-specific lists. Client administrators see open, waiting-on-you, resolved, and all-ticket views with ticket reference, subject, owner, status, reply/comment summary, and last update time. Other customer roles use the standard ticket table with status, priority, category, requester, created date, and a linked-call shortcut when one is present. Partner users see an assigned-client queue with client, requester, owner, status, priority, category, and updated time. Open a ticket to review its details and status history; customer attachment-read roles can also review clean attachments.

You can add a comment when you have more information or need to clarify the request. Keep comments focused on the issue and avoid adding secrets or unnecessary personal information.

Ticket detail initially loads the newest 50 comments available in each visibility stream. When older history exists, Load earlier comments fetches the next fixed page from the server and prepends it in chronological order. The control reports loading, retry, loaded-count, and beginning-of-history states. A failed page leaves the comments already on screen available, and a successful prepend preserves the reader's position and keyboard focus.

Customer-facing roles can page customer-visible comments according to their Support access. Partner administrators see the customer-visible and internal columns side by side and can page each one independently. Each column has its own filtered total and continuation cursor, so internal activity cannot affect the customer-visible window or reveal its existence to customer-facing roles. A newly submitted comment is inserted at the newest end of its column without resetting the anchored older-history cursor or duplicating loaded rows.

The client-administrator ticket list supports open, waiting, resolved, and all-ticket views. Subject search is scoped to the selected tenant context and rejects wildcard-style search strings so another organisation's ticket subjects cannot be probed through broad search filters. When more tickets are available, Previous and Next preserve the selected view, search, and page size; changing the view or search starts again from the first page, and an out-of-range page is redirected to the last available page.

#Statuses

Some status changes are performed by support or by users with the required role. Partner administrators, AiDial administrators, and AiDial operators can perform valid status transitions. Customer roles can only reopen a resolved or closed ticket. If a status action is not visible, your current role may not be allowed to make that change.

#Access and Scope

Customer users see tickets for their own organisation. Partner users see tickets only for clients assigned to their partner account. Access is checked by the portal each time a ticket is listed, opened, paged, commented on, or updated.

The browser talks to portal route handlers under /api/support/** and /api/shell/support/open-count, plus /api/calls/{callId}/related-tickets for the internal reverse lookup. Those handlers use the signed-in NextAuth/Zitadel session and forward a server-side bearer token to aidial_api; the browser is not expected to send X-API-Key. Non-API Support pages are protected by middleware, while support API routes enforce their own session, endpoint-specific RBAC, CSRF for protected mutations, rate limits, audit, and tenant/client scope. Ticket detail and comment-history reads also constrain non-null ticket source projects to the bearer session's server-derived project set; project-null account/client tickets retain their client-scoped behavior. Denied or out-of-scope resources use the same not-found response so that the portal does not reveal whether a ticket or file exists.

Ticket pages avoid exposing whether another organisation has a matching ticket or call reference. If a ticket is outside your scope, the portal shows a not-found style response.

Related-call checks follow the same scoping rule. A call from another tenant or from a project outside the user's assignment is treated as unavailable, even if the caller knows the call reference.

The Support sidebar badge shows the number of open tickets for eligible roles. Client administrators and client managers see their own organisation count; partner users see their assigned-client count. Client staff do not receive the badge. The badge refreshes from the signed-in portal session about once per minute, hides zero and error states, and does not accept a browser-supplied client ID.

List badges and waiting counts use stored support-ticket aggregates from the API. Customer roles see customer-visible comment counts and support-reply state only; partner and AiDial support roles can use their broader support scope without exposing client ids in summary counts.

#Good Ticket Descriptions

Helpful tickets usually include:

• what you were trying to do
• the page or workflow where the issue happened
• the approximate date and time
• the project or client name, if your role manages more than one
• any visible error message, without secrets
• what you expected to happen

Avoid screenshots that reveal callers' personal information unless support specifically asks for a redacted example.

#Common Issues

#Related Pages

• Signing In
• Roles & Permissions
• Partner Escalation