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
