DEV Community: AbhiJeet Sachan

Building Scalable Support Ticket System with Node.js, Express & MongoDB – Part 3

AbhiJeet Sachan — Wed, 30 Jul 2025 21:17:50 +0000

HelpMe – Part 3: Expanding Backend Features with Admin & Agent Routes

In the previous part of this series, we built the foundation of ticket management: creating tickets, listing user tickets, and retrieving single tickets.
Now, we’ll extend the backend to handle real-world workflows by introducing admin and agent capabilities, closing tickets, and improving our schema.

This post is a continuation of Part 2 – if you haven’t read it, I recommend checking that out first.

Goals of Part 3

By the end of this post, we will:

Update the Ticket schema to include timestamps and new fields.

Add routes for:

Admin: assign tickets, view tickets by user
Agent: view assigned tickets, close tickets
Strengthen role-based access control using middleware.
Add threaded replies so tickets have conversations.
Allow agents and users to reply to tickets.
Build admin dashboard analytics routes.
Add user profile APIs (view/update profile).
Discuss minor updates to our previous code where necessary.

These steps bring us closer to a multi-role support system, where tickets can flow seamlessly between users, agents, and admins.

1. Updating the Ticket Schema

Why?

To track ticket history with createdAt/updatedAt.
To record which agent is assigned to a ticket.
To manage ticket lifecycle statuses (open, in-progress, closed).

File:models/Ticket.js

import mongoose from 'mongoose';

const ticketSchema = new mongoose.Schema({
  title: "{ type: String, required: true },"
  description: "String,"
  priority: { type: String, enum: ['low', 'medium', 'high'], default: 'low' },
  status: { type: String, enum: ['open', 'in-progress', 'closed'], default: 'open' },
  createdBy: { type: mongoose.Schema.Types.ObjectId, ref: 'User', required: true },
  assignedTo: { type: mongoose.Schema.Types.ObjectId, ref: 'User', default: null }
}, {
  timestamps: true
});

export default mongoose.model('Ticket', ticketSchema);

Note: timestamps: true automatically adds createdAt and updatedAt fields.

Mongoose Methods You’ll See Often
Before we jump into the routes, let’s clarify common Mongoose methods:

1. find(query):
Fetches all documents matching the query.
Example:

Ticket.find({ createdBy: userId })

Returns an array of tickets.

findById(id):
Finds a document by its unique MongoDB _id.
Returns a single document or null.
findByIdAndUpdate(id, update, options):
Finds a document by _id, updates it, and (if { new: true } is passed) returns the updated document.
populate(field, select):
Replaces an ID stored in a field with the actual referenced document.
Example:

.populate('assignedTo', 'username')

This will include the assigned agent's username in the result.

sort({ field: -1 }):
Sorts the query results. -1 means descending order, 1 means ascending.

These methods are crucial to querying MongoDB effectively.

2. Building Admin and Agent Features

We’ll add new controller functions in controllers/ticketController.js.

Admin: Assign Tickets
Why?
Admins should be able to assign a ticket to an agent, moving its status to in-progress.

Route: POST /api/tickets/assign/:ticketId

Controller Code:

export const assignTicket = async (req, res) => {
  try {
    const { agentId } = req.body;
    const ticket = await Ticket.findByIdAndUpdate(
      req.params.ticketId,
      { assignedTo: agentId, status: 'in-progress' },
      { new: true }
    ).populate('assignedTo', 'username');

    if (!ticket) return res.status(404).json({ message: 'Ticket not found' });

    res.json(ticket);
  } catch (error) {
    console.error(error);
    res.status(500).json({ message: 'Error assigning ticket' });
  }
};

How it works:

We use findByIdAndUpdate() to update the assignedTo field and set the status to in-progress.

{ new: true } ensures we get the updated document back.
.populate() fetches agent details so you don’t need another query.

Admin: View Tickets by User
Why?
Admins often need to see all tickets created by a specific user for auditing or follow-up.

Route: GET /api/tickets/user/:userId

Controller Code:

export const getTicketsByUser = async (req, res) => {
  try {
    const tickets = await Ticket.find({ createdBy: req.params.userId })
      .sort({ createdAt: -1 })
      .populate('assignedTo', 'username');

    res.json(tickets);
  } catch (error) {
    console.error(error);
    res.status(500).json({ message: 'Error fetching user tickets' });
  }
};

Agent: View Assigned Tickets
Why?
Agents need a dedicated list of tickets assigned to them.

Route: GET /api/tickets/assigned
Controller Code:

export const getAssignedTickets = async (req, res) => {
  try {
    const tickets = await Ticket.find({ assignedTo: req.user.id })
      .sort({ updatedAt: -1 });
    res.json(tickets);
  } catch (error) {
    console.error(error);
    res.status(500).json({ message: 'Error fetching assigned tickets' });
  }
};

Close a Ticket
Why?
Agents (for their own tickets) and admins should be able to close tickets, changing their status to “closed.”

Route: PUT /api/tickets/:ticketId/close
Controller Code:

export const closeTicket = async (req, res) => {
  try {
    const ticket = await Ticket.findById(req.params.ticketId);
    if (!ticket) return res.status(404).json({ message: 'Ticket not found' });

    const { role, id } = req.user;

    // Only assigned agent or any admin can close
    if (role === 'agent' && ticket.assignedTo?.toString() !== id) {
      return res.status(403).json({ message: 'Agents can only close their own tickets' });
    }

    ticket.status = 'closed';
    await ticket.save();
    res.json(ticket);
  } catch (error) {
    console.error(error);
    res.status(500).json({ message: 'Error closing ticket' });
  }
};

3. Securing Routes with Middleware

We use roleMiddleware to protect these routes:

import { roleMiddleware } from '../middleware/roleMiddleware.js';

router.post('/assign/:ticketId', roleMiddleware(['admin']), assignTicket);
router.get('/user/:userId', roleMiddleware(['admin']), getTicketsByUser);
router.put('/:ticketId/close', roleMiddleware(['admin', 'agent']), closeTicket);
router.get('/assigned', roleMiddleware(['agent']), getAssignedTickets);

This ensures:

Only admins can assign or view all tickets.
Agents can only view their assigned tickets.
Agents can close only their own tickets.

Testing

Use Postman to test these routes:

Assign a ticket: POST /api/tickets/assign/:ticketId with agentId in JSON body.
View tickets by user: GET /api/tickets/user/:userId
Close a ticket: PUT /api/tickets/:ticketId/close
View assigned tickets (as agent): GET /api/tickets/assigned

4.1. Why Replies Are Important

So far, a ticket was just a title and description.
But in a real support system, tickets involve conversation threads between the user and the agent.
We need a way to store these replies.

4.2. Adding a Message Schema

Why a separate schema?
Keeping messages in their own collection makes it easier to:

Scale conversations
Query by ticket
Manage who sent each message

Code: models/Message.js

import mongoose from 'mongoose';

const messageSchema = new mongoose.Schema({
  ticket: { type: mongoose.Schema.Types.ObjectId, ref: 'Ticket', required: true },
  sender: { type: mongoose.Schema.Types.ObjectId, ref: 'User', required: true },
  content: { type: String, required: true }
}, { timestamps: true });

export default mongoose.model('Message', messageSchema);

Key points:

ticket links the message to a ticket.
sender is the user or agent who sent the reply.
timestamps lets us track the conversation history in orde r.

5. Reply Routes

Update Needed in Old Code
In routes/ticketRoutes.js, we need to add verifyToken middleware (if not already added) so only logged-in users/agents can reply.

POST /api/tickets/:ticketId/replies
Purpose: Add a reply to a ticket.

Controller (controllers/messageController.js):

import Message from '../models/Message.js';
import Ticket from '../models/Ticket.js';

export const addReply = async (req, res) => {
  try {
    const { content } = req.body;
    const ticket = await Ticket.findById(req.params.ticketId);

    if (!ticket) {
      return res.status(404).json({ message: 'Ticket not found' });
    }

    // Only admin, agent, or ticket creator can reply
    if (
      req.user.role === 'agent' &&
      ticket.assignedTo?.toString() !== req.user.id
    ) {
      return res.status(403).json({ message: 'Agents can only reply to their assigned tickets' });
    }

    if (
      req.user.role === 'user' &&
      ticket.createdBy.toString() !== req.user.id
    ) {
      return res.status(403).json({ message: 'Users can only reply to their own tickets' });
    }

    const message = await Message.create({
      ticket: ticket._id,
      sender: req.user.id,
      content
    });

    res.status(201).json(message);
  } catch (error) {
    console.error(error);
    res.status(500).json({ message: 'Error adding reply' });
  }
};

GET /api/tickets/:ticketId/replies
Purpose: Fetch all replies for a given ticket.

Create a controller getReply, try the logic yourselves.
_Hint: It will use this query- Message.find({ ticket: req.params.ticketId }) _

Adding Routes
In routes/messageRoutes.js:

import express from 'express';
import { verifyToken } from '../middleware/authMiddleware.js';
import { addReply, getReplies } from '../controllers/messageController.js';

const router = express.Router();

router.post('/:ticketId/replies', verifyToken, addReply);
router.get('/:ticketId/replies', verifyToken, getReplies);

export default router;

6. Admin Dashboard Analytics

Why?

Admins need insights like:

How many tickets are open/closed
Which agents have the most assigned tickets
Ticket resolution rates

Controller (controllers/adminController.js
We’ll use MongoDB aggregation to compute statistics.

import Ticket from '../models/Ticket.js';

export const getDashboardStats = async (req, res) => {
  try {
    const totalTickets = await Ticket.countDocuments();
    const openCount = await Ticket.countDocuments({ status: 'open' });
    const closedCount = await Ticket.countDocuments({ status: 'closed' });
    const inProgressCount = await Ticket.countDocuments({ status: 'in-progress' });

    // Count tickets grouped by agent
    const agentWorkload = await Ticket.aggregate([
      { $match: { assignedTo: { $ne: null } } },
      { $group: { _id: '$assignedTo', count: { $sum: 1 } } },
      { $sort: { count: -1 } }
    ]);

    res.json({
      totalTickets,
      openCount,
      inProgressCount,
      closedCount,
      agentWorkload
    });
  } catch (error) {
    console.error(error);
    res.status(500).json({ message: 'Error fetching dashboard stats' });
  }
};

Now, Register these routes in your routes/adminRoutes.js.

7. User Profile Routes

Users should be able to:

View their profile
Update their username or email (but not their role)

Controller (controllers/userController.js)

import User from '../models/User.js';

export const getProfile = async (req, res) => {
  try {
    const user = await User.findById(req.user.id).select('-password');
    res.json(user);
  } catch (error) {
    console.error(error);
    res.status(500).json({ message: 'Error fetching profile' });
  }
};

export const updateProfile = async (req, res) => {
  try {
    const { username, email } = req.body;
    const user = await User.findById(req.user.id);

    if (username) user.username = username;
    if (email) user.email = email;

    await user.save();
    res.json({ message: 'Profile updated', user });
  } catch (error) {
    console.error(error);
    res.status(500).json({ message: 'Error updating profile' });
  }
};

What We Achieved in Part 3

We extended our backend to handle multi-role workflows:
Admins can assign tickets and audit users.
Agents can view and close tickets assigned to them.
We explained important Mongoose methods for beginners.
We enforced strict role-based access control.
Threaded replies: A new Message schema and routes for conversations.
Reply permissions: Users and assigned agents can reply; no one else.
Analytics: Admin dashboard stats with MongoDB aggregation.
User profile APIs: Users can view and update their details securely.

GitHub Repo: github
If you did not read the last part-part-2

This concludes Part 3 of the series. If you are new to backend development, take time to understand the query methods and role-based design—they are essential for building secure, scalable systems.
We now have a full conversation layer and analytics capabilities built into our backend!

What’s Next
In the next post, we will:

Integrate Cloudinary for attachments.
Add AI-powered sentiment analysis & auto-tagging.
Begin frontend work with React/Next.js to bring everything together visually.

Building Scalable Support Ticket System with Node.js, Express & MongoDB – Part 2

AbhiJeet Sachan — Sat, 12 Jul 2025 22:23:44 +0000

In this follow‑up, we’ll implement the ticket creation, user ticket listing, and single ticket view endpoints . You’ll learn why we choose specific methods, how we structure controllers, and what’s coming next.

Quick Recap (Part 1)

Project setup with Express, Mongoose, environment variables, and cookie‑based JWT auth

Schemas: User and Ticket models with proper validations and references

Authentication: register/login/logout routes with bcrypt hashing and HTTP‑only cookies

Middleware: verifyToken to validate JWTs, and roleMiddleware() for access control

Objectives of This Post

Create a ticket (POST /api/tickets)
List my tickets (GET /api/tickets/my-tickets)
View a single ticket (GET /api/tickets/:ticketId)

You’ll see how we:

Organize controllers to separate business logic from routes
Use Mongoose methods for efficient querying and population
Return consistent responses and handle errors gracefully

Controller Setup

A controller is a module or function responsible for handling the logic associated with a specific route or set of routes. It acts as an intermediary between the incoming HTTP request (handled by the route) and the application's data and services.

Things to Remember When Defining a Controller in Express-
Each controller should do one thing well: handle the logic for a single route or resource.

// example
const getUserById = (req, res) => {
  const userId = req.params.id;
  // fetch user logic
};

1. Use req, res, and _next _Properly

Use req to access request data
Use res to send response
Use next() to pass errors or call next middleware

const getUser = (req, res, next) => {
  try {
    // Logic here
    res.status(200).json({ message: 'User found' });
  } catch (err) {
    next(err); // Pass error to error-handling middleware
  }
};

2. Return Consistent Response Structure

res.status(200).json({
  success: true,
  data: user,
  message: "User fetched successfully"
});

Maintain:

success: true/false
data: ...
message: ...
Use status codes properly, for more check this npm package http-status-codes

This helps to handle responses easily.

First, let’s create a controllers/ticketController.js to house our ticket logic:

controllers/ticketController.js

import Ticket from '../models/Ticket.js';

// @desc    Create a new ticket
// @route   POST /api/tickets
// @access  Private (user)
export const createTicket = async (req, res) => {
  try {
    const { title, description, priority } = req.body;
    const ticket = new Ticket({
      title,
      description,
      priority,
      createdBy: req.user.id
    });
    const saved = await ticket.save();
    res.status(201).json(saved);
  } catch (err) {
    console.error(err);
    res.status(500).json({ message: 'Server error creating ticket' });
  }
};

// @desc    Get tickets for logged‑in user
// @route   GET /api/tickets/my-tickets
// @access  Private (user)
export const getMyTickets = async (req, res) => {
  try {
    const tickets = await Ticket.find({ createdBy: req.user.id })
      .sort({ createdAt: -1 });
    res.json(tickets);
  } catch (err) {
    console.error(err);
    res.status(500).json({ message: 'Server error fetching tickets' });
  }
};

// @desc    Get single ticket by ID
// @route   GET /api/tickets/:ticketId
// @access  Private (user, agent, admin)
export const getTicketById = async (req, res) => {
  try {
    const ticket = await Ticket.findById(req.params.ticketId)
      .populate('createdBy', 'username email');
    if (!ticket) {
      return res.status(404).json({ message: 'Ticket not found' });
    }
    res.json(ticket);
  } catch (err) {
    console.error(err);
    res.status(500).json({ message: 'Server error fetching ticket' });
  }
};

Later we'll be updating these logics if needed to scale and optimize our app.

Why This Approach?

Dedicated Controller: Keeps route definitions clean and focuses on business logic here.
new Ticket() + .save(): Straightforward Mongoose pattern to create and persist documents.
Ticket.find(): Efficiently retrieves user‑specific tickets. We sort by creation date for UX.
.sort() ensures newest tickets appear first
populate(): Automatically replaces ObjectId fields with user details, avoiding extra client requests.
Error Handling: Catches unexpected failures and returns a 500 status with a clear message.

Defining the Routes

Next, wire up these controllers in routes/ticketRoutes.js

// routes/ticketRoutes.js

import express from 'express';
import {
  createTicket,
  getMyTickets,
  getTicketById
} from '../controllers/ticketController.js';
import { verifyToken } from '../middleware/verifyToken.js';

const router = express.Router();

// All routes under /api/tickets are private
router.use(verifyToken);

router.post(
  "/create",
  verifyToken,
  roleMiddleware(["user"]),
  createTicket
);
router.get("/my-tickets", verifyToken, getMyTickets);
router.get("/:ticketId", verifyToken, getTicketById);

export default router;

Here, we have used the verifyToken, which is a middleware and it makes sure the user is authenticated or not. if not authenticated, the user will not be able to see tickets.

Middleware: Functions that have access to the request object (req), the response object (res), and the next middleware function in the application's request-response cycle

How to create a middleware: a middleware is a normal function that requires three argument: req, res, next. it has access to req and res, and end the request-response cycle, or pass control to the next middleware in the stack.

const middlewareFunction = (req, res, next) => {
  // Your logic here
  console.log('Middleware executed');
  next(); // Pass control to the next middleware or route handler
};

for more details on middleware check express official website

Then import this in server.js/index.js:
import ticketRoutes from './routes/ticketRoutes.js'; app.use('/api/tickets', ticketRoutes);
Now We are done with Ticket creation endpoints and User‑specific ticket listing.
The next step is to create admin routes to -

View all tickets by user
Assigning tickets to agents
Agent endpoints – view assigned tickets
Threaded replies using a conversation schema

Note: In previous post we have created a new middleware roleMiddleware that authenticates the user by their roles(user, agent or admin).
Further in this app, wherever we need to authenticate or to check the user by thier roles, we have to use this middleware.

Challenge yourself: Create a deleteTicket controller to delete tickets(only user can do) by yourself.

Tips:

Get tickets from params: const { ticketId } = req.params;
Find ticket by id, if no ticket found return- No tickets found. Otherwise delete the ticket by findByIdAndDelete method.
Use try, catch block properly.

Next Steps:

We are going to create admin routes and agent routes to
-Assign tickets(for admin)
-Get tickets by user Id(admin)
-Close a ticket(admin, agent)
-See assigned tickets(agent)

Before defining these routes, We need some changes in our Ticket schema-
To check/assign the tickets we have to add a key to Ticket schema:

assignedTo:  { type: mongoose.Schema.Types.ObjectId, ref: 'User', default: null }

Creating controllers

assignTicket controller-

Assign a ticket to an agent
POST /api/tickets/assign/:ticketId
Access: Admin

import Ticket from '../models/Ticket.js';
export const assignTicket = async (req, res) => {
  try {
    const { agentId } = req.body;
    const ticket = await Ticket.findByIdAndUpdate(
      req.params.ticketId,
      { assignedTo: agentId, status: 'in-progress' },
      { new: true }
    );
    if (!ticket) return res.status(404).json({ message: 'Ticket not found' });
    return res.json(ticket);
  } catch (err) {
    console.error(err);
    return res.status(500).json({ message: 'Error assigning ticket' });
  }
};

Uses findByIdAndUpdate to set assignedTo and move status to “in‑progress.”
Returns the updated document via { new: true }

getTicketsByUser Controller:

Get all tickets raised by a specific user
GET /api/tickets/user/:userId
Access: Admin

export const getTicketsByUser = async (req, res) => {
  try {
    const tickets = await Ticket.find({ createdBy: req.params.userId })
      .sort({ createdAt: -1 })
      .populate('assignedTo', 'username');
    return res.json(tickets);
  } catch (err) {
    console.error(err);
    return res.status(500).json({ message: 'Error fetching user tickets' });
  }
};

Filters by createdBy to fetch all tickets a given user has opened.
Populates assignedTo.username so the admin sees who’s handling each ticket.

closeTicket controller:

Close a ticket (either admin or agent)
PUT /api/tickets/:ticketId/close
Access: Admin, Agent

export const closeTicket = async (req, res) => {
  try {
    const ticket = await Ticket.findById(req.params.ticketId);
    if (!ticket) return res.status(404).json({ message: 'Ticket not found' });

    // Only assigned agent or any admin may close
    const { role, id } = req.user;
    if (role === 'agent' && ticket.assignedTo?.toString() !== id) {
      return res.status(403).json({ message: 'Agents can only close their own tickets' });
    }

    ticket.status = 'closed';
    await ticket.save();
    return res.json(ticket);
  } catch (err) {
    console.error(err);
    return res.status(500).json({ message: 'Error closing ticket' });
  }
};

Fetches the ticket, checks permissions (agent may only close their own).
Sets status = 'closed' and saves—triggering an updatedAt timestamp update.

getAssignedTickets controller

Get tickets assigned to the logged-in agent
GET /api/tickets/assigned
Access: Agent

export const getAssignedTickets = async (req, res) => {
  try {
    const tickets = await Ticket.find({ assignedTo: req.user.id })
      .sort({ createdAt: -1 }) // newest first
      .populate("createdBy", "username email role") // optional: enrich with user info
      .populate("assignedTo", "username email");

    if (!tickets.length) {
      return res.status(404).json({ message: "No assigned tickets found" });
    }
    return res.status(200).json({ tickets });
  } catch (error) {
    console.error("Error fetching assigned tickets:", error);
    return res
      .status(500)
      .json({ message: "Failed to fetch assigned tickets" });
  }
};

Agents retrieve only tickets where assignedTo === req.user.id.
Sorting by updatedAt surfaces the most recently active tickets first.

Route Definitions

Wire these into routes/ticketRoutes.js and protect them with roleMiddleware.

import express from 'express';
import {
  createTicket,
  getMyTickets,
  getTicketById,
  assignTicket,
  getTicketsByUser,
  closeTicket,
  getAssignedTickets
} from '../controllers/ticketController.js';
import { verifyToken } from '../middleware/verifyToken.js';
import { roleMiddleware } from '../middleware/roleMiddleware.js';

const router = express.Router();
router.use(verifyToken);

// Admin only
router.post(
  '/assign/:ticketId',
  verifyToken,
  roleMiddleware(['admin']),
  assignTicket
);
router.get(
  '/user/:userId',
  verifyToken,
  roleMiddleware(['admin']),
  getTicketsByUser
);

// Admin & Agent can close
router.put(
  '/:ticketId/close',
  verifyToken,
  roleMiddleware(['admin','agent']),
  closeTicket
);

// Agent only
router.get(
  "/assigned",
  verifyToken,
  roleMiddleware(["agent"]),
  getAssignedTickets
);

export default router;

Note:
To ensure agents can only interact with their own tickets:

Enforce roleMiddleware(['agent']) on any agent‑specific endpoints (/assigned, later “reply” routes).
In closeTicket, verify req.user.id === ticket.assignedTo.toString() before allowing closure.
In future reply/message controllers, always check that the actor is either the ticket creator or the assigned agent.

Summary of Changes

Schema: added timestamps: true.
Controllers: four new methods for assignment, user‑scoped listing, closing, and agent‑scoped listing.
Routes: protected with verifyToken + roleMiddleware for precise access control.

Final Notes

What We’ve Covered in This Post (Part 2):

Implemented ticket creation (POST /api/tickets) with input validation and error handling
Built user ticket listing (GET /api/tickets/my-tickets) with filtering, sorting, and field projection
Created single ticket retrieval (GET /api/tickets/:ticketId) leveraging .populate() for rich user data
Added admin routes: ticket assignment and fetching by user ID
Added agent routes: viewing assigned tickets and closing tickets securely
Demonstrated how to protect endpoints with verifyToken and roleMiddleware
Updated the Ticket schema to include timestamps for audit trails

What’s in Next Parts

Admin endpoints: list all tickets, fetch by user ID
Agent actions: view assigned tickets, add replies
Adding cloudinary database to store files
Conversation threads: design a Message schema and link to tickets
AI integration: outline methods for auto‑tagging and sentiment

Previous Post: To better understand this project read the previous post Part-1

🔗 Explore & Contribute

All code is on GitHub—feel free to fork, star, and suggest improvements:
Helpme github-repo

Follow me on Dev.to or LinkedIn for the next parts of this series.
Got questions or feedback? Let me know in the comments — happy to help!

Building a Scalable Support Ticket System with Node.js, Express & MongoDB

AbhiJeet Sachan — Tue, 01 Jul 2025 13:53:32 +0000

Part 1: Backend Foundation creating a Ticket raising platform

A practical guide to creating real-world backend systems using Mongoose, Express middleware, and secure authentication.

Introduction

Customer support systems are an essential part of any tech-driven business, and building one from scratch is a great way to learn full-stack development with real-world requirements.

In this series, I'm documenting the development of HelpMe, an AI-powered support ticket system built using the MERN stack (MongoDB, Express, React, Node.js). The goal is to simulate a production-grade ticketing platform with:

Role-based access (user, agent, admin)
JWT-based authentication
Ticket lifecycle management
Modular, scalable backend structure
AI features (coming soon)

This post will cover the backend foundation — ideal for anyone looking to build a professional-grade project using Express and MongoDB.

Github repo

Project Structure

Organizing files in a clean, modular way is key to scaling your backend efficiently. Here's how the backend is structured:

Environment Setup

Initialize the project

npm init -y
npm install express mongoose dotenv cookie-parser bcryptjs jsonwebtoken

Create the entry file

// server.js

import express from 'express';
import mongoose from 'mongoose';
import dotenv from 'dotenv';
import cookieParser from 'cookie-parser';

dotenv.config();
const app = express();

app.use(express.json());
app.use(cookieParser());

// Routes (example)
import authRoutes from './routes/auth.js';
app.use('/api/auth', authRoutes);

// Connect to MongoDB
mongoose.connect(process.env.MONGO_URI)
  .then(() => app.listen(5000, () => console.log('Server running')))
  .catch(err => console.error('MongoDB connection failed:', err));

Defining the Schemas

User Schema // models/User.js

import mongoose from 'mongoose';

const userSchema = new mongoose.Schema({
  username: { type: String, required: true, trim: true, unique: true },
  email:    { type: String, required: true, trim: true, lowercase: true, unique: true },
  password: { type: String, required: true, minlength: 6 },
  role:     { type: String, enum: ['user', 'admin', 'agent'], default: 'user' }
});

export default mongoose.model('User', userSchema);

Ticket Schema // models/Ticket.js

import mongoose from 'mongoose';

const ticketSchema = new mongoose.Schema({
  title:       { type: String, required: true },
  description: { type: String },
  priority:    { type: String, enum: ['low', 'medium', 'high'], default: 'low' },
  status:      { type: String, enum: ['open', 'in-progress', 'closed'], default: 'open' },
createdBy: {type: mongoose.Schema.Types.ObjectId, ref: "User",    required: true,
    },
});

export default mongoose.model('Ticket', ticketSchema);

Why Schema Design Matters

Relationships like createdBy and assignedTo are handled using MongoDB references (ObjectId), enabling efficient population and querying.

Enumerations ensure valid values for priority, status, and role, enforcing business rules at the DB level.

Authentication System

Register, Login & Logout

Auth routes include: POST /register – Create a user account

POST /login – Authenticate and store JWT in an HTTP-only cookie

POST /logout – Clear the authentication cookie

// routes/auth.js
import express from 'express';
import bcrypt from 'bcryptjs';
import jwt from 'jsonwebtoken';
import User from '../models/User.js';

const router = express.Router();

router.post('/register', async (req, res) => {
  const { username, email, password } = req.body;
  const hashed = await bcrypt.hash(password, 10);
  const user = new User({ username, email, password: hashed });
  await user.save();
  res.status(201).json({ message: 'Registration successful' });
});

router.post('/login', async (req, res) => {
  const { email, password } = req.body;
  const user = await User.findOne({ email });
  if (!user || !(await bcrypt.compare(password, user.password))) {
    return res.status(401).json({ message: 'Invalid credentials' });
  }

  const token = jwt.sign({ id: user._id, role: user.role }, process.env.JWT_SECRET);
  res.cookie('token', token, { httpOnly: true });
  res.status(200).json({ message: 'Login successful' });
});

router.post('/logout', (req, res) => {
  res.clearCookie('token');
  res.status(200).json({ message: 'Logged out' });
});

export default router;

Middleware: Secure Access

To protect routes and limit access based on roles, we add two middlewares:

Verify JWT

// middleware/verifyToken.js
import jwt from 'jsonwebtoken';

export const verifyToken = (req, res, next) => {
  const token = req.cookies.token;
  if (!token) return res.status(401).json({ message: 'Unauthorized' });

  jwt.verify(token, process.env.JWT_SECRET, (err, decoded) => {
    if (err) return res.status(403).json({ message: 'Invalid token' });
    req.user = decoded;
    next();
  });
};

Role-Based Access

// middleware/roleMiddleware.js
export const roleMiddleware = (roles) => (req, res, next) => {
  if (!roles.includes(req.user.role)) {
    return res.status(403).json({ message: 'Access denied' });
  }
  next();
};

This system allows you to protect endpoints like:

app.get('/tickets/all', verifyToken, roleMiddleware(['admin']), controller);

What’s Covered So Far

Project structure & setup ✅ Done
User & Ticket schemas ✅ Done
Auth routes (/register, /login, /logout) ✅ Done
JWT & role-based middleware ✅ Done

Coming in Part 2

Next, I’ll cover:

Ticket creation and viewing routes
Admin: Assign ticket to agent
Agent dashboard: View assigned tickets
Threaded replies using a conversation schema
Integrating AI models for tagging & sentiment

Final Notes

If you're looking to build a full-featured backend using modern Node.js practices — especially for multi-role apps — this architecture is production-ready and extendable.

Feel free to explore, clone, or contribute to the project below.

🔗 GitHub Repo: https://github.com/Abhijeet002/HelpMe-AI-Powered-Support-Ticket-System

Follow me on Dev.to or LinkedIn for the next parts of this series.
Got questions or feedback? Let me know in the comments — happy to help!

DEV Community: AbhiJeet Sachan

Building Scalable Support Ticket System with Node.js, Express & MongoDB – Part 3

Goals of Part 3

1. Updating the Ticket Schema

2. Building Admin and Agent Features

3. Securing Routes with Middleware

** Testing**

4.1. Why Replies Are Important

4.2. Adding a Message Schema

5. Reply Routes

6. Admin Dashboard Analytics

7. User Profile Routes

Building Scalable Support Ticket System with Node.js, Express & MongoDB – Part 2

Quick Recap (Part 1)

Objectives of This Post

Controller Setup

Next Steps:

Route Definitions

Final Notes

What’s in Next Parts

🔗 Explore & Contribute

Building a Scalable Support Ticket System with Node.js, Express & MongoDB

Part 1: Backend Foundation creating a Ticket raising platform

Introduction

Project Structure

Environment Setup

Defining the Schemas

Why Schema Design Matters

Authentication System

Register, Login & Logout

Middleware: Secure Access

Verify JWT

Role-Based Access

What’s Covered So Far

Coming in Part 2

Final Notes

Testing