Will's Birthday Sale — 86% off all products. Ends October 19 at 11:59 AM.
KodeBaseKODEBASE
Back to Prompt Library
App Building

Add a Complete Built-In Support Workflow & Ticketing System

Add a native support system — help requests, ticket management, status tracking, priority tagging, staff assignment, internal notes, reply threads, file uploads, customer notifications, and a simple knowledge base.

The prompt
Scan my entire Base44 app first so you fully understand how it currently works before making changes.

Analyze the full app: pages, layouts, data models, backend functions, automations, user flows, navigation, permissions, forms, and current admin areas. Identify how users contact you, how records are stored, and where a support workflow fits naturally.

After understanding the app, add a complete support workflow that feels native.

GOAL: a built-in support system that lets users request help, lets staff manage tickets, and gives both sides visibility into status.

1. APP UNDERSTANDING FIRST — Scan before building. Map users, accounts, forms, notifications, files, admin access. Reuse existing design patterns, components, routes, roles, and naming. No duplicate systems, no broken workflows/forms/automations/permissions.

2. SUPPORT WORKFLOW — Help request form, ticket system, status tracking, priority tagging, assigned team member, internal notes for staff, reply history, file uploads for screenshots/proof, customer notifications on status change, simple knowledge base.

3. USER-FACING FEATURES — A "Get Help"/"Support" CTA in a logical place; help request form (subject, category, description, priority if appropriate, file upload); ticket history for the user's own tickets; status display (New, Open, Waiting on Customer, In Progress, Resolved, Closed); full reply thread inside each ticket; notifications on status change; a simple help center/knowledge base with common Q&A.

4. ADMIN / SUPPORT STAFF FEATURES — View all tickets; filter by status/priority/category/assigned staff/date; search by customer/email/account/ticket number; assign tickets; update status; internal staff-only notes; view reply history; upload/review files; timestamps for created/updated/assigned/replied/resolved; respond to customers directly.

5. TICKET STRUCTURE — Ticket ID, customer/account reference, subject, description, status, priority, category, assigned team member, internal notes, reply history, attachments, created/updated/resolved dates, last customer reply date, last staff reply date.

6. PERMISSIONS — Customers see only their own tickets; support staff access support tools only with permission; admins have full visibility; internal notes NEVER visible to customers; protect all routes, data, and actions.

7. NOTIFICATIONS — Ticket submitted, status changed, staff replied, ticket resolved. Use the existing notification system if present, otherwise build a simple in-app + email flow.

8. KNOWLEDGE BASE — Search/category browsing; FAQ articles with title/category/summary/content; admin can create/edit/publish/unpublish/organize; place access near the support form so users self-serve first.

9. INTEGRATION RULES — Fit the current app structure, reuse user/account relationships, reuse admin dashboard patterns, reuse file uploads, reuse notification logic, consistent UI.

10. BUILD QUALITY — Identify what exists, what must be added, what pages/entities/functions/automations need creating or updating, then fully implement.

11. FINAL OUTPUT — Summary of current app, existing support systems, what you added, new entities, pages/admin sections, backend functions, permissions approach, and recommended next improvements.

Rules: don't remove existing features without necessity; don't assume without scanning; extend existing support/contact/messaging systems rather than rebuilding; production-ready, end-to-end for both staff and customers.
App Building
#support
#tickets
#knowledge base