Skip to main content

Support Requests Management

As a tenant or platform administrator, you use Support Requests to create tickets, monitor workload, and move issues from first report to resolution without leaving the Admin Portal. You see how many items are open or waiting on you, filter the list when volume grows, and open each ticket for full context and messaging. For broader product documentation outside the portal, see the Booga Enterprise documentation site.

Overview​

Support Requests gives you a single place to create, track, and resolve support tickets. The page opens with summary statistics so you grasp volume and state at a glance, then presents a sortable, paginated table of requests. You refine the list with search and filters, create new tickets from a floating action control, and open any row for the full detail view with conversation history and status changes.

The experience is built for both day-to-day triage and occasional submissions: you can scan Total and Open counts before you filter, or jump straight to Waiting to clear customer follow-ups. Color cues on status and priority help you spot urgency without reading every cell.

Prerequisites​

Before you rely on this area, confirm the following:

  • You hold an Admin or SuperUser role (or equivalent) so the Admin Portal and Support Requests are available to your account.
  • Your tenant has an active subscription so platform services backing tickets and notifications behave as expected.

If you cannot reach Support Requests at all, verify your role and tenant status first; those gates apply before any ticket-specific troubleshooting.

Dashboard Stats​

Across the top of the page, summary cards reflect the current dataset (respecting any filters where the product applies them consistently). Use them as a health dashboard for support workload:

  • Total — Count of all requests in the current view or scope, giving you a baseline for how large the queue is.
  • Open — Tickets that are newly submitted or not yet actively owned; these typically need triage or assignment.
  • In Progress — Items your team is actively working; good signal for current engineering or support load.
  • Waiting — Requests that need a response from the customer or tenant side before work can continue; these stall resolution if ignored.
  • Resolved — Issues where a solution has been provided but the ticket is not formally closed yet; you may still follow up or confirm.
  • Closed — Finalized requests that no longer need action; useful for historical volume and reporting.

Cards use color to align with status semantics: open states draw attention (Open as warning, In Progress as informational, Waiting as needing attention, Resolved as success, Closed as neutral or subdued). Glance at the row of cards before you dive into the table so you know whether you are clearing a backlog or handling steady flow.

Viewing Requests​

Requests appear in a DataGrid-style table that supports sorting and pagination. Columns include ID, Title, Status, Priority, Category, Tenant, Created, Last Activity, Messages, and Actions. You use ID and Title to find a specific thread; Status, Priority, and Category summarize state and routing; Tenant matters when you operate across tenants; Created and Last Activity help you see stale tickets; Messages shows how much conversation has occurred and may surface unread indicators so you notice new replies.

Status Types​

Statuses describe where a ticket sits in its lifecycle. Labels and colors align so you can scan quickly:

  • Open — Newly submitted and awaiting triage or first response; shown with a warning-style emphasis so nothing sits unnoticed.
  • In Progress — Under active review or implementation; informational styling indicates work in flight.
  • Waiting for Customer — Blocked until the requester (or your tenant) supplies information, approval, or confirmation; error-style emphasis reminds you that the ball is often on the customer side.
  • Resolved — A solution or answer has been delivered; success styling reflects completion of the main work.
  • Closed — The ticket is finalized and archived for operational purposes; neutral styling suits read-only history.

Move tickets through these states as your process dictates; the visual system is there so anyone opening the page understands backlog versus blocked versus done.

Priority Levels​

Priority tells you how urgently the request should be handled relative to others. Values are Low, Normal, High, and Urgent, each with distinct color treatment—generally calmer tones for lower urgency and stronger tones for High and Urgent so escalations stand out in the grid. When you create or edit requests, set priority honestly: mislabeled Urgent items dilute trust in the queue.

Categories​

Categories route work and help reporting. Choose the label that best matches the problem:

  • Technical — Platform, integration, or infrastructure behavior; use when the issue is about how the system runs or connects.
  • Billing — Subscriptions, invoices, payment methods, and plan changes.
  • Feature Request — Enhancement ideas and product direction feedback rather than defect reports.
  • Bug Report — Something that used to work or clearly violates expected behavior.
  • Account — Access, identity, roles, and user lifecycle within your tenant or organization.
  • Other — Anything that does not fit cleanly above so it still lands in a tracked queue.

Accurate categories speed up assignment and keep metrics meaningful when you review trends later.

When the list grows, use the filter and search panel above the table to narrow results:

  • Search — Free-text search across request titles so you can find a ticket by keyword or subject fragment.
  • Status — Dropdown to limit rows to one lifecycle state, such as Open or Waiting for Customer.
  • Priority — Dropdown to focus on High, Urgent, or any single level.
  • Category — Dropdown to see only Billing, Technical, or another category.

After you adjust filters, use Clear to reset all criteria and return to the full default view. Use Refresh to reload data from the server when you expect new messages or status changes—for example after a colleague updates a ticket in another session.

If results look empty, check whether a forgotten filter or search term is hiding rows before you assume nothing exists.

Creating a Request​

To submit a new ticket, click the floating + button at the bottom-right of the screen. The Create Support Request dialog opens so you can enter a clear Title, a detailed Description, Category, and Priority, then submit. Write descriptions with enough context—steps to reproduce for bugs, account or subscription identifiers for billing—that the recipient can act without a long back-and-forth. After creation, the new request appears in the table and counts toward the dashboard stats.

Viewing Request Details​

Open a ticket in full context by clicking the row or using the view action in Actions. You navigate to the dedicated request detail experience where you see the full thread, status history, and any actions your role allows (such as updates or replies, depending on product configuration). Use this view when you need to read the entire conversation or change state—not just scan the list.

On smaller viewports, the product may offer a details modal or quick view so you can inspect key fields without leaving the list; on larger screens you still benefit from the full page for lengthy threads.

Responsive Design​

The table adapts to screen size so you can triage from a phone or a wide monitor:

  • Mobile — You see ID, Title, and Actions to keep the layout readable. Use the info affordance where provided to open a details modal for a quick read without navigating away.
  • Tablet — Adds Status and Priority so you can sort urgency and state without opening each row.
  • Laptop — Adds Category for routing context while still saving horizontal space.
  • Desktop — Shows all columns, including Tenant, dates, and Messages, for full operational visibility.

If you usually work on mobile, plan to open the full detail view when you need dates or tenant columns that are hidden in the compact layout.

Best Practices​

  • Check the stats row daily or on a schedule that matches your SLA so Open and Waiting counts do not silently grow.
  • Prioritize Waiting for Customer when your process requires user input—those tickets often unblock the fastest once you respond.
  • Align Category and Priority with reality so dashboards and escalations reflect true risk.
  • Use Refresh after bulk operations or when collaborating so you are not acting on stale rows.
  • Close or finalize tickets only after the requester confirms resolution where your policy requires it, keeping Resolved versus Closed meaningful.

Troubleshooting​

  • No requests showing — Confirm you have not left a restrictive Search term or a Status / Priority / Category filter active. Choose Clear, then Refresh.
  • Cannot create a request — Verify your account has admin access to the portal and that your tenant subscription is active; role and entitlement issues block creation before ticket validation runs.
  • Stats or rows feel stale — Click Refresh to pull the latest counts and table data; if the product caches aggressively, a refresh is the first step before reporting a platform issue.

If problems persist after these checks, use your internal escalation path or Booga Enterprise support channels documented on the documentation site.

⏱️ Read time: 8 minutes | 📊 Difficulty: beginner