This solution is designed for teams that need a ticketing system that can grow and evolve with real business needs. Instead of a fixed, one-off setup, it focuses on extensibility, configurable workflows, and AI-assisted handling to reduce repetitive work while keeping humans in control.
A few key ideas behind this solution:
An extensible ticket model that supports different business scenarios
Unified ticket intake across multiple channels
Built-in SLA tracking as part of the workflow
Gradually turning resolved tickets into reusable knowledge
The solution is still evolving. Some capabilities are intentionally simple in the current version, and we plan to keep iterating based on real-world usage and community feedback.
If you’ve built, customized, or used a ticketing system before, we’d really love to hear from you:
What ticketing scenarios do you deal with most often?
Where do existing ticketing systems usually fall short in practice?
What would you expect from an AI-powered ticketing setup in real work?
Here are a few useful links if you’d like to explore further:
First of all, I think this demo app is a great initiative. It is a perfect way.to see concrete examples and learn from them, so I’m very happy that the Nocobase team is working on these kinds of demos!
I have built a number of ticketing systems using different local based apps and from my experience what tends to be important in practice is the following:
Traceability, seeing what changed and when, this seems to be implemented quite well.
Warnings and notifications for overdue items, I haven’t looked at all workflows in detail, so I’m not sure this is included.
Usually managers also want to get an idea of how quickly the different team members deal with their tickets. This seems to be implemented well in the dashboards.
Documents such as the QA articles in the demo usually require some type of versioning, and an owner who is responsible for keeping these procedures up to date.
What I noticed is that this demo uses a lot of JavaScript fields and columns. This flexibility is nice, but it also shows that the current blocks and fields are somewhat lacking. Native features that would be very welcome are:
conditional formatting (background, font colors, icons etc.) of fields based on record data
Finally, Roles and permissions are always important. Who is allowed to edit tickets at each stage? Can you still edit tickets after they have been completed and if such must you provide a justification or approval? If a refund must be given, is there a refund approval workflow?
Hopefully this feedback is somewhat useful to you guys. Thanks again for creating and sharing this great example.
Thank you so much for your detailed feedback and valuable insights! Let me address each of your points:
Regarding Warnings and Notifications
SLA due alerts are already implemented — you can find “SLA Resolve Due Notification” and “SLA Response Due Notification” workflows in the system. As for overdue reminders, we plan to add corresponding workflows in future versions, but they will be disabled by default since the demo data contains many overdue tickets, which would generate excessive notifications.
Regarding Document Versioning
Full version control is indeed challenging within the current framework. However, we do provide a “Record History” feature that can be used to track and display the modification history of QA documents, meeting basic traceability needs.
Regarding Roles and Permissions
To keep the demo solution minimal and focused, the current permission controls are admittedly not comprehensive. This is one of our key priorities for future iterations, and we will continue to improve it in upcoming versions.
Regarding UI Components
We’ve noted your requests for conditional formatting, button-style option groups, filter buttons, and other features. Future versions will introduce more flexible UI components, which will be delivered as “lightweight plugins/components” for easy adoption.
Thanks again for trying out the solution and sharing your insights! Your feedback is incredibly valuable to us
Hi all, @Lijia@AlbertMa ,
we are currently deciding whether to start using NocoBase at our company (mainly for Ticketing). Would be great if you could help us with these questions:
Can our customer open a ticket by sending email to dedicated support email inbox (like support@company.com)?
Does user get immediate info that ticket was created and also link to access that ticket in the web interface of NocoBase? Can this be configured? Mainly we want for the users to be able to interact with tickets both via email or web interface.
If we reply to that ticket within NocoBase, I assume the customer will receive email notification with that reply. But what if the user replies via email to that notification? Will it add it to the existing ticket or create a new one? And based on what is this matched? I haven’t found any info about this.
For email-opened tickets, can we manually assign them to client’s profile/account within NocoBase, so they are able to see all their tickets after log in?
Do we need plugin plugin-email-manager to use the email ingest funcitonality? Are we able to test this on community edition first, before purchasing? We use Entra ID at the company, but I’m not sure if our IT dept. will allow to assign those permissions like IMAP.AccessAsUser.All - is that scoped to the specific inbox in use?
If we couldn’t use this email connector, is there an IMAP connector or can we develop our own?
Ticket emails about replies are sent via this email plugin too, or is that standard SMTP?
Thanks for your interest in using NocoBase for your ticketing system!
Regarding your technical questions, here are the details:
1. Creating tickets via Email & Plugin Requirements Yes, this is possible, but it works a bit differently than traditional SaaS helpdesks.
Plugin: You will need the plugin-email-manager.
Protocols: Currently, this plugin supports Gmail and Outlook via their official HTTP APIs (not generic IMAP/SMTP). This ensures better stability and security than standard IMAP.
Workflow: To “convert” an email into a ticket, you would set up a Workflow in NocoBase:
Trigger: When an email is received in the inbox.
Action: Create a record in the “Tickets” collection.
Note on Spam: Since this receives all emails, we suggest adding a rule in the workflow to filter content. You can even add an AI node to intelligently parse the email intent and filter out spam or irrelevant messages before creating a ticket.
Current Status: The “bi-directional sync” (where a user’s email reply automatically appends to an existing ticket as a comment) is not enabled by default in the current Ticketing template.
Possibility: While not out-of-the-box, it is technically possible to implement. You would need to develop custom logic (e.g., matching email headers or subject IDs) to route the reply to the correct ticket. We are considering adding this native capability in future updates.
3. Notifications & Links Yes, this is fully configurable. You can add an “Email Node” in your workflow to send an immediate confirmation to the user. You can include dynamic variables in the email body, such as the specific URL/Link to the created ticket, allowing them to access the web interface directly.
4. Assigning Tickets Yes. You can manually assign the “Owner” or “Client” field for any ticket. By configuring NocoBase’s ACL (Access Control Layer) permissions, you can ensure that when a client logs in, they only see the tickets linked to their profile.
5. Customization & Entra ID Since the Email Manager uses the Outlook/Graph API, the permissions are determined by the API scope. If the standard plugin permissions (AccessAsUser.All) are too broad for your IT department, or if you need a generic IMAP connector, you might need to:
Fork/modify the existing plugin to adjust scopes (if applicable).
Or develop a custom plugin/connector to fit your specific security compliance. NocoBase is designed to be extensible for these exact scenarios.
Solution overview: https://www.nocobase.com/en/solutions/ticketing-v2
Design and background article: AI-Powered Ticketing Built with NocoBase 2.0 - NocoBase
Documentation: https://v2.docs.nocobase.com/solution/ticket-system/
