SupportHubCX Platform Docs
v1.0.0 Public Support Open App

Configuration

After installation, most runtime behavior is configured from the admin UI. The database-backed Settings module overrides many Laravel defaults at runtime so admins can tune the app without editing files.

Environment Values

Use .env for infrastructure-level settings: app environment, debug mode, database connection, cache store, queue connection, filesystem disk, Redis, and provider credentials that should not be edited by normal admins. Use Settings for app behavior, branding, mail, security, sessions, OTP/TOTP, and tools.

First Admin Checklist

  1. Open /settings and confirm app URL, timezone, date format, currency, and branding.
  2. Open Email & Delivery Channels and send a test email.
  3. Set password policy, lockout policy, email verification behavior, OTP policy, and TOTP issuer.
  4. Create roles or adjust the seeded Admin and Agent roles.
  5. Create departments and users, then assign each user a role and department.
  6. Create ticket setup records: categories, priorities, statuses, SLA policies, tags, custom fields, mailboxes, reply templates, FAQ entries, business hours, and holidays.
  7. Create organizations, support teams, requesters, and support contracts.
  8. Enable automations, webhooks, API clients, report schedules, status components, and identity providers only after the base data is stable.

Scheduler Configuration

Ticket SLA checks, scheduled reports, and time-based automations depend on Laravel's scheduler. The server must run Laravel's scheduler all the time through cron. Do not rely on a browser tab being open.

VPS or Dedicated Server

On a VPS, add this cron entry for the Linux user that owns the app files, often www-data, forge, ploi, or the deployment user:

* * * * * cd /var/www/supporthub && /usr/bin/php artisan schedule:run >> /dev/null 2>&1

Replace /var/www/supporthub with the real project path and /usr/bin/php with the path returned by:

which php

Shared Hosting or cPanel

In cPanel Cron Jobs, Plesk Scheduled Tasks, or a similar hosting panel, create a cron job that runs every minute if the host allows it:

* * * * * /usr/local/bin/php /home/USERNAME/supporthub/artisan schedule:run >> /home/USERNAME/supporthub/storage/logs/cron.log 2>&1

Replace USERNAME, the project path, and the PHP binary path with the values from the hosting account. Some shared hosts use /usr/bin/php, /opt/cpanel/ea-php82/root/usr/bin/php, or a PHP version selector path.

If the host only allows cron every 5, 10, or 15 minutes, use the shortest interval available. Reports may be delivered late by that interval, but they should still send when the scheduler next runs.

Scheduled Report Command

The scheduled report worker is:

php artisan reports:send-scheduled

Laravel already calls this command hourly through routes/console.php. For normal production, keep the main schedule:run cron entry instead of adding a separate cron entry for every command.

Manual test from the project root:

php artisan reports:send-scheduled

The command finds active report schedules whose next_run_at is due, generates the saved report, queues or sends the email attachment, updates last_run_at, calculates the next next_run_at, and writes the Operations Center heartbeat reports:send-scheduled.

If a host cannot run schedule:run but can run a single cron command, this direct fallback runs only scheduled reports:

0 * * * * cd /var/www/supporthub && /usr/bin/php artisan reports:send-scheduled >> /var/www/supporthub/storage/logs/scheduled-reports.log 2>&1

Use the fallback only when needed. It will not run SLA checks or ticket automations; the full app should use php artisan schedule:run.

Queue note: Scheduled report emails use queued notifications. With QUEUE_CONNECTION=sync, delivery happens during the command. With database, redis, or another async queue, the command queues the emails and a running queue:work process must send them.

Queues

QUEUE_CONNECTION=sync is simple and works locally, but production systems should use a worker for slower tasks such as email, scheduled report delivery, and background processing.

php artisan queue:work --tries=3 --timeout=120

Permission-Aware UI

The sidebar is built from user permissions. A user who cannot see Tickets, Platform Ops, Integrations, or Settings probably lacks the related permission. Use Roles & Permissions to grant access instead of editing menu code.