Find the cause of a support-workspace issue
Work from a specific symptom to the checks that help identify and resolve its cause.
On this page
Overview
Blank Inbox: empty REST payload, 401/403, or JS error — diagnose Network for /tickets and bootstrap, then hard-refresh; cache on /wp-json/elegant-support/ is a common cause. Filter not opening: overlay JS/CSS failed, custom CSS overflow, or a stale build — expected UI is a popover (desktop) or drawer (mobile), never a panel that pushes rows down. REST 401/403: expired cookie/nonce or missing elegant_support_* cap; 401 usually session, 403 usually permission. Session expired: log in again; do not keep retrying POST. Customer not found: wrong id, archived record, or guest chat without email yet.
When to use this
Email not received: IMAP unavailable, inbound off, poll error, provider block, or cron idle. Email not sent: SMTP auth, forbidden From, queue backlog, failed/bounced on #/settings/channels/logs. IMAP unavailable: PHP extension missing. Queue backlog: WP-Cron on a quiet site, fatals in jobs, batch too small — open System Status first. These failures cluster because one cron feeds mail, SLA, automation, and webhooks.
Where to find the controls
Start at #/settings/system/system, then the module screen (Inbox, Email logs, SLA, Automation logs, Live Chat settings, Form Builder, Integrations logs). Flush permalinks at WordPress Settings → Permalinks when REST 404 or portal/KB URLs die. Documentation is the sidebar item above Free/Dev (#/docs).
Who can make these changes
Support Admin diagnoses host/REST/cron. Agents report symptoms (blank list, handoff waiting forever) and must not be asked for SMTP passwords. Contact HelSup when Status is healthy but the symptom remains, or when portal IDOR is confirmed.
Before you begin
SLA incorrect: calendar/holiday mismatch, engine off, queue stale, policy conditions never match — fix hours then wait for a tick. Automation not running: draft/inactive, conditions, engine limits, same queue. KB hidden: basic_kb off, missing view_kb, or unpublished. AI no answer / no evidence: unindexed, internal article, grounded empty retrieval, provider test fail, or human-only mode. None of these need a new AI engine.
Follow these steps
Live chat not showing: feature off, shortcode missing, JS blocked, cache. Handoff failing: handoff disabled, nonce, REST error on public/chat/session/handoff, notify off, humans offline by business hours, empty Live Chat view. Form field missing: surface/conditional. Attachment rejected: Tickets size/type. Portal 404: feature, slug, permalinks, unpublished page. WooCommerce unavailable: plugin inactive (helpdesk still works). Webhook failed: non-2xx, TLS, queue. Dark mode: Appearance tokens / data-es-theme. Knowledge Base translations require separately authored article bodies. Permalink: flush, then retest REST and public URLs.
Settings reference
For each symptom record: what you saw, HTTP status, System Status chip, cron last run, queue depth, feature flags, role caps, and whether custom CSS/cache plugins are active. Delivery log fields: status, transport, error_message. Chat: retrieval_status. Inbox: filter badge vs empty list.
Example workflow
Symptom: visitors say chat vanished after a theme update. Cause: the theme stopped printing [elegant_support_chat]. Diagnosis: view-source has no widget root. Solution: restore the shortcode. Contact support only if the shortcode is present, live_chat is on, and JS still never mounts.
Good practices
Exclude REST from caches. Hard-refresh after every plugin update. Test Inbox filters after custom CSS. Export tickets before uninstall. Prefer system cron before rewriting SLA policies.
Important considerations
Do not DROP wp_helsup_support_ tables to “fix schema”. Do not disable nonce/rate limits on production. Do not paste keys into a support ticket. Confirmed portal IDOR is a security incident. Use the supported integration for any additional channel.
If something does not work
When to contact support: System Status healthy, permalinks flushed, cache excluded, cron current, and the bug still reproduces on two browsers. Send installed plugin version, failed test name, HTTP status, retrieval_status or delivery error_message, session/ticket id — never SMTP passwords, license keys, or customer dumps. If uninstall behaviour is unclear: export first, then follow WordPress plugin deletion; wipe only if remove_data_on_uninstall was enabled.