Frappe Helpdesk with ERPNext for customer support: when the built-in support module stops being enough
If your ERPNext team runs customer support in the Issue module and is weighing whether to add Frappe Helpdesk, the short answer is this: Frappe Helpdesk is an open source ticket management app that the Frappe team built because the ERPNext support module's UI and UX fell short, and it is designed to integrate with an existing ERPNext system rather than sit beside it as a separate silo. The Helpdesk README states this motivation directly, so the question for your team is less about whether the tool exists and more about whether your agents, customers and reporting needs are being served by the Issue module today.
This page is written for the people who usually make that call: CIOs and heads of IT who own the ERPNext footprint, support operations leads who feel the interface friction daily, and the platform engineers who would have to add a second app to the same bench. Implementers are typically the ERPNext partner or internal platform team, since the work touches the Frappe app set, the deployment image and the user roles that govern who can see customer records. Every version number, date and release reference in this section comes from the supplied facts, and where a detail is not confirmed, we say what to verify with the Frappe project or in your own environment.
The sections that follow cover the decision criteria, how the two apps share one bench, and the verification steps before go-live. Treat the first step as an audit of your current Issue workflows: list the agent actions, queue views and customer-facing touchpoints you actually use, then test each one against Helpdesk in a non-production site before committing.
What Frappe Helpdesk adds for customer support teams
Frappe Helpdesk is an open source ticket management tool that the Frappe team built because the ERPNext support module did not meet their needs for UI and UX. The cards below cover what it changes for support teams and what to verify in the repository before you commit to a split between Helpdesk and the ERPNext support module.
Purpose-built ticket interface
The Helpdesk README states that Frappe built the app because the ERPNext support module was not good in UI and UX. For agents, that means the ticket queue and conversation view are the primary workspace rather than a form inside the ERP. Ask your support leads to walk through the agent screens in a test site and compare them with the daily workflow they run today, including how they triage, reassign and reply.
Integration with your ERPNext system
Frappe built Helpdesk to integrate with its existing system, which is the practical reason to choose it alongside ERPNext. Tickets can sit next to the customer and related records your team already maintains in the ERP. Confirm in the repository which ERPNext records are linked from a ticket and whether your customer and item data needs cleanup before go-live.
Shared bench deployment
Helpdesk runs on the same Frappe bench as ERPNext, so it shares the database, workers, scheduler and upgrade cycle with the ERP. This keeps operations in one place but also means a Helpdesk change can affect ERP work on the same site. Plan a staging bench that mirrors production and test both apps together before any upgrade.
Single custom image build
The frappe_docker build guide shows an apps.json that installs ERPNext and Frappe HR from the version-16 branch with Helpdesk from its main branch in one custom image. Pinning branches this way means Helpdesk does not follow ERPNext automatically. Decide which Helpdesk branch you run, record it in your build file, and retest the image on every rebuild.
Retiring the support module
Moving customer support to Helpdesk means deciding what happens to existing ERPNext support issues, service level agreements and maintenance records. Those are separate workflows in ERPNext, so Helpdesk does not replace every after-sales function automatically. List which ERPNext support records are still used by finance, field service or warranty teams and confirm how Helpdesk handles them before you switch.
Features to confirm before rollout
Specific capabilities such as support channels, agent views and a customer-facing portal should be checked against the current Helpdesk repository rather than assumed. The repository is the source of truth for what the app does today. Ask for a written list of features that your intake channels, reporting and customer access depend on, and mark any gap as a question for the Helpdesk project or a custom build.
Keep the support module or move to Frappe Helpdesk
This table compares three ways to run customer support on ERPNext: keeping the built-in support module, moving front-line ticketing to Frappe Helpdesk, or running both with clear record ownership. Read each row against your own service model, since the right answer depends on who opens tickets, who owns after-sales obligations, and where warranty and maintenance records must live.
| Decision point | Keep the ERPNext support module | Move front-line ticketing to Frappe Helpdesk | Run both with defined ownership |
|---|---|---|---|
| Best fit | After-sales service tied to serial numbers, maintenance schedules and warranty claims | High ticket volume from customers who need a cleaner agent and requester interface | Front-line tickets handled in Helpdesk, with escalations to ERPNext for service and warranty records |
| Customer workflow | Customers and agents work in the ERPNext issue screens | Customers raise tickets in Helpdesk and receive updates there | Customers see one ticket thread, while service actions are recorded in ERPNext |
| Agent workflow | Agents stay in ERPNext, close to billing, stock and service documents | Agents need training on a separate interface and its routing rules | Agents triage in Helpdesk and hand off to ERPNext records when a service action is needed |
| Warranty and SLA checks | Checked against serial numbers and service level agreements in ERPNext | Must be rebuilt or linked to ERPNext data before use | Warranty decisions stay in ERPNext, with the ticket reference copied across |
| Record ownership | One system holds issues, visits and claims | Helpdesk holds ticket history, ERPNext holds commercial records | Define which system owns each field and status, and who may edit it |
| Integration effort | Minimal, since it is already part of ERPNext | Requires installing Helpdesk on the same bench and mapping customers and contacts | Requires a documented link between ticket and issue records, tested before go-live |
| Confirm before choosing | Whether the ERPNext support features meet your interface and routing needs | The Helpdesk version and branch you will run alongside your ERPNext version, and its support status | Which system is the source of truth for customer, contact and warranty data |
How Frappe Helpdesk and ERPNext run on one bench
A bench is the Frappe command line environment that manages sites, apps and background processes on one server or a small group of servers. ERPNext can be installed manually with the bench command line tool, as the ERPNext README describes. Helpdesk is added the same way: you fetch its app into the bench, install it on the site that already runs ERPNext, and run migrations on each update. Both apps then share one database per site, one scheduler and one set of workers, so a single deployment handles accounting records and support tickets.
- App installation: Fetch Helpdesk into the bench and install it on the same site as ERPNext, not a separate one, if tickets must link to customers and invoices.
- Version pairing: Keep Helpdesk on a release that matches your ERPNext major version, and check the Helpdesk README before each bench update.
- Shared workers: Background jobs for both apps run in the same worker and scheduler processes, so queue capacity must cover email and automation from both.
- Upgrade order: Plan ERPNext and Helpdesk upgrades together in a staging copy of the site, since a migration on one app can affect the other.
- Backups: A single site backup covers both apps' data, which simplifies restore testing.
Confirm with your platform team which Helpdesk release is compatible with your ERPNext major version before you run the first install.
The frappe_docker project provides production images and Compose files for ERPNext and other Frappe apps. Its build guide uses an apps.json file to define which apps go into a custom image. The example in the guide installs ERPNext and Frappe HR from the version-16 branch and Helpdesk from its main branch in one image. Your team then runs that image with the same MariaDB, Redis, worker, scheduler, Socket.io and Nginx services that the production setup uses.
- Custom image: Build one image that contains ERPNext, Frappe HR and Helpdesk, so every container runs identical app code.
- Branch choice: The guide's
mainbranch for Helpdesk is a moving reference, so pin a specific commit or tag in your ownapps.jsonfor repeatable builds. - Compose services: Background workers and the scheduler must run the same image version as the web containers, or migrations and jobs can fail.
- Evaluation limits: The single-file demo setup is intended for short-lived evaluation, so do not use it as the base for a production deployment.
- Registry and rebuilds: Each app update means a new image build, a registry push and a controlled migration window.
Verify that the Helpdesk branch or tag you pin supports the ERPNext version in your image before the first build.
Frappe Cloud is the hosted option for ERPNext, with plans listed on the ERPNext pricing page. Shared site hosting starts at 5 US dollars per month, and servers start at 20 US dollars per month for shared instances and 125 US dollars per month for dedicated servers, according to that page. Those figures are list starting points, so ask for a quote that includes the exact site plan, storage, and whether Helpdesk is available as an app on your chosen plan. Frappe Cloud availability for each app should be confirmed in writing before design work begins.
- App availability: Confirm that Helpdesk can be installed on the plan and bench type you select, since hosted app catalogs can differ from self-managed benches.
- Server Scripts: Server Scripts are disabled by default from version 15 and must be enabled with
server_script_enabled. Frappe Cloud public shared benches do not allow them, so any ticket routing logic written as server scripts needs a dedicated bench or a custom app. - Support coverage: Frappe's supported versions policy ties warranty coverage to a listed version and a matching Frappe Cloud support plan.
- Customization path: Moving routing rules into a custom app keeps them portable if you later change hosting.
- Data residency: Confirm where hosted data is stored if your ticket data includes personal information.
Before you commit, ask the vendor to confirm Helpdesk availability and Server Script permissions for the exact plan you are buying.
The implementation sequence from app installation to agent go-live
The sequence moves from confirming compatible versions and building one image to mapping customers and roles, carrying open tickets across, and cutting over agents and customers with a tested path. Each step ends with a named artifact so the team can see whether it is finished before the next one starts.
Confirm ERPNext and Helpdesk versions and branches
The platform owner and the ERPNext administrator record the ERPNext version the production site runs, then check that the Helpdesk branch you plan to install is built for that same major version. Confirm the Frappe support status of your ERPNext version on the supported versions page before you commit, since an unsupported base changes the upgrade path for everything that follows. The output is a short compatibility record listing ERPNext, Frappe Framework, Frappe HR if present, and the Helpdesk branch, signed off by both the platform owner and the support lead.
Build the custom image or bench
The DevOps or platform engineer adds the chosen apps to an apps.json file and builds a custom image with the frappe_docker build process, or installs the same apps on a bench for a non-container host. Pin each app to an explicit branch or tag so that a rebuild six months later produces the same code. The output is a tagged image or bench with a recorded app list, which is tested in a staging environment with no production data before anything else happens.
Install and configure Helpdesk against the existing site
The ERPNext administrator installs the Helpdesk app on a copy of the production site, runs the migration, and checks that the ERPNext support module and Helpdesk do not both expose the same ticket workflows to agents. Decide which Helpdesk settings govern agent teams, ticket categories, and customer portal visibility, and document them. The output is a staging site where the app loads cleanly, the scheduler and background workers run, and the configuration is written down in a form someone else could repeat.
Map customers, contacts and support roles
The ERPNext administrator and the support lead match existing Customer and Contact records to the people who will open tickets, and decide which contacts get portal access. Map each support responsibility to a Frappe role, then confirm that the role permissions in ERPNext and Helpdesk give agents what they need and nothing more. The output is a role matrix that lists each role, the DocTypes it can read and write, and the named owners who approved it.
Migrate or run open tickets in parallel
The support lead chooses between moving open issues into Helpdesk and leaving them in the old module until they close. Moving them requires a mapping of status, priority, owner and customer fields, and a test import of a small sample before the full set, since the Data Import tool is documented for batches of a few thousand records at a time. Running in parallel avoids the import but means agents work in two places for a period. The output is either a reconciled count of migrated tickets with a sample check, or a written rule for which system owns each open ticket.
Configure agent and customer access
The identity owner and the ERPNext administrator set how agents sign in, whether through the existing ERPNext login policies or a configured social login or LDAP source, and confirm that customers reach only the portal pages for their own company. Test password, two-factor and session settings with a representative agent and a customer account. The output is a sign-in checklist per user group that has been run against staging and signed off.
Test the full ticket path end to end
The QA lead runs scripted scenarios that cover a customer opening a ticket through the portal, an email or form intake, assignment to an agent team, a reply, an escalation, a link to a sales or service record in ERPNext, and closure. Each scenario is repeated after any configuration change. The output is a test log with pass or fail for each scenario, a list of defects with owners, and a retest result for every defect before the cutover date is set.
Cut over with a documented checklist
The project owner runs the cutover from a written checklist that covers the final data sync or freezing of the old module, the production image deployment, DNS or portal link changes, the scheduler and worker check, a backup taken immediately before the switch, and a named rollback decision point. Agents and customers are told what changes and where to go. The output is a completed checklist with timestamps and the signature of the project owner, followed by a short review of the first days of live use.
What drives the cost and duration of a Helpdesk rollout
This table lists the main drivers behind the effort of moving support work from the ERPNext Support module to Frappe Helpdesk, with how each one raises effort and how to keep it manageable. Read each row as a question to settle in the scope document before a quote is agreed, since the largest swings usually come from queue design, history migration and identity choices.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number of queues and agents | Each queue needs its own routing rules, agent groups, roles and test cases, and more agents means more permission checks to verify. | Start with a small set of queues mapped to real teams and add others after go-live. |
| Volume and history of Issue records | Large numbers of existing Issue records, attachments and comments take longer to map, clean and test than a fresh start. | Decide early which history to migrate and archive the rest in read-only form. |
| Customer and contact integration | Tickets must link to ERPNext Customer, Contact and Address records, so duplicate or inconsistent master data adds cleaning work. | Deduplicate customers and contacts in ERPNext before the migration run, not during it. |
| Identity and login choices | Connecting customer and agent logins to LDAP, Social Login Key or an external identity provider adds configuration and access testing. | Confirm the identity source and which user types need access before the build begins. |
| Hosting model | Running Helpdesk on the same bench as ERPNext needs a custom image or shared build pipeline, while Frappe Cloud limits what can be configured. | Confirm with the Frappe Cloud plan or your own infrastructure which apps and server scripts are allowed. |
| Testing depth | Testing ticket routing, email intake, SLA timers, permissions and migration reconciliation takes more time as coverage expands. | Agree a fixed set of test cases tied to the queues and integrations in the written scope. |
| Email and channel intake | Mailboxes, forwarding rules and inbound email handling must be configured and tested per address. | Limit the first release to the channels support teams actually use and record the rest for later. |
How Helpdesk connects to ERPNext and the rest of your platform
Frappe Helpdesk is a separate app, but it runs on the same Frappe bench as ERPNext and shares its data model, users and sign-in. The cards below cover the connection points to check before you design around them, and each Helpdesk-specific behavior should be confirmed against the Helpdesk repository first.
ERPNext customer and contact records
Helpdesk tickets are expected to reference the customers and contacts already held in ERPNext, so support staff see the same account history as sales and billing. Confirm in the Helpdesk repository which ERPNext DocTypes it reads and writes, and whether a ticket can be created from an existing customer without duplicating the record. Decide early who owns contact data when a customer changes its address or details.
Frappe Framework login and roles
Helpdesk users sign in through the same Frappe user accounts and roles that govern ERPNext. This means a support agent's access to tickets is set by role and user permissions, not by a separate Helpdesk user list. Confirm which Helpdesk roles exist in the version you deploy and test that an agent cannot open ERPNext financial records through a ticket link.
LDAP sign-in for staff
ERPNext supports LDAP login against Active Directory or OpenLDAP, with SSL/TLS options and automatic mapping of LDAP groups to ERPNext roles at each login. Because Helpdesk uses the same user accounts, the same directory setup can cover agents, provided group-to-role mapping is designed with support roles in mind. Confirm that Helpdesk logins behave as ERPNext logins do before you rely on this path.
Social login for customers and partners
Frappe's Social Login Key feature lets users sign in with providers such as Google, Microsoft or GitHub, or with custom OAuth or OpenID Connect endpoints. Use it to decide how external users reach a support portal without creating full internal accounts. Confirm with the Helpdesk repository whether its customer-facing pages accept the same social login configuration before you promise it to customers.
Email delivery for ticket threads
Support replies and customer messages depend on outgoing and incoming email configured for the bench. Plan which email account sends ticket notifications, how replies are threaded back to tickets, and how bounces are handled. Confirm in the Helpdesk repository how it receives mail and whether it needs a dedicated mailbox, because a misconfigured inbox is a common cause of lost customer messages.
Other apps on the same bench
When Helpdesk is installed with ERPNext and Frappe HR in one custom image, the apps share one database, one scheduler and one set of background workers. Changes to one app's version can affect the others, so upgrades must be tested together. Confirm the supported version pairing in the Helpdesk repository and in the frappe_docker build setup before you fix the apps.json file.
Frequently asked questions about Frappe Helpdesk with ERPNext
Does Frappe Helpdesk replace the ERPNext Issue module entirely?
Not automatically. Frappe Helpdesk is a separate open source ticketing app that the Frappe team built because the ERPNext support module's interface fell short on UI and UX, and it was designed to integrate with the existing system. Whether it replaces the Issue module depends on what your support team does day to day, which customer records and reports depend on Issues, and whether anyone still uses the Issue workflows. Map every Issue-based process, report and integration before deciding. Some organizations move agents to Helpdesk while keeping historical Issues for reference, and others migrate or retire them in a planned cutover. Confirm the current feature overlap in the Helpdesk repository and test it against your real ticket types.
What drives the cost of a Helpdesk rollout, and do we need a partner?
The cost is driven by scope rather than by the app itself, which is open source. The main components are the analysis of current support processes, configuration of queues, roles and SLAs, any integration with ERPNext customers, contacts and items, hosting and build work for the custom image, testing, training and cutover. A partner is paid for that work, and an in-house team pays for the same hours through its own staff. Platform costs are separate: check the ERPNext pricing page for hosting options, and the supported versions page for which versions and support plans apply. Ask any provider for a quote built from a written scope that lists the queues, integrations, environments and test cases included.
How long does a Helpdesk implementation take, and what does that depend on?
Duration depends on how many ticket channels, queues, SLAs and integrations are in scope, how clean the existing support data is, and how quickly your process owners can make decisions. A single queue with a few agents and a clear customer master is far shorter to set up than several regional queues with contract-based SLAs and bidirectional data flows. Plan time for a proof of concept on a staging bench, a round of user testing with real support staff, and a cutover window. Any timeline should come from the written scope and be confirmed with the provider. Ask for the milestones and the dependencies on your team, not only a total.
What must our team provide for a Helpdesk project?
The project needs three things from your side. First, named process owners for support, sales and finance who can approve queue design, SLA rules and escalation paths. Second, support data in usable form: existing Issues, customer and contact records, item lists, and any ticket exports from the current tool, with known quality problems listed. Third, test users who work in support every day and can run realistic ticket scenarios, including edge cases like reopened tickets and cross-team handoffs. Also agree who owns the server, backups and access accounts after handover. Missing any of these usually extends testing and rework, so confirm the responsibilities in the scope before work starts.
Can an in-house team build and run Helpdesk on ERPNext without a partner?
Yes, if the team has Frappe and ERPNext experience and the scope stays small. The work involves a bench or Docker build with the Helpdesk app, configuration of queues and roles, and careful testing of permissions, since support agents should see tickets without seeing unrelated finance or sales data. The frappe_docker build setup shows how an apps.json file can combine ERPNext, Frappe HR and Helpdesk into one custom image, which helps keep versions aligned. The harder parts are the migration decisions, integration testing and ongoing upgrades. Be honest about who will maintain it after go-live, and compare that cost with an external scope.
How do ERPNext version upgrades affect the Helpdesk app?
Helpdesk has to stay compatible with the ERPNext and Frappe Framework version you run, so every ERPNext upgrade needs a compatibility check before it reaches production. Frappe lists which versions are supported and when they end support, so a move off an unsupported release should be planned early. The frappe_docker build pins app branches, and the Helpdesk branch you use may differ from the ERPNext branch, so confirm the matching pair in the Helpdesk repository before building. Run the upgrade on a copy of the production site, test ticket creation, SLA timers, email notifications and permissions, and keep a tested backup before cutover. Ask any provider how they handle this for your version pair.
What are the main risks when running Helpdesk beside the ERPNext support module?
The main risks are duplicate records, split reporting and unclear ownership. If Issues and Helpdesk tickets both accept new work, customers may receive answers from two places and managers will not get one view of service levels. Decide early which system is the system of record for each ticket type and when the old Issue entry points are closed. Another risk is permissions: a ticket can expose customer or invoice details to agents who should not see them. Test role access with real accounts, and review email routing and SLA calculations before go-live.
How DeployOpen scopes and delivers a Frappe Helpdesk implementation
DeployOpen plans and delivers Frappe Helpdesk alongside ERPNext inside infrastructure you control, starting from a written scope that names the customer records, channels and bench layout involved. Each stage produces documented deliverables you can review before the next one begins. Engagements are fixed-scope, and ongoing support is available as a retainer after go-live.
How we scope
- We document which support channels, customer records and ERPNext data Helpdesk will read and write.
- We map the current ERPNext support module use, including issues and SLAs, to decide what moves.
- We record the bench, site and image layout in the written scope before any build work starts.
- We confirm with you which Helpdesk version and app branch will be pinned and why.
How we build
- We build a custom image that bundles ERPNext, Frappe HR where needed and Helpdesk on one bench.
- We configure agent roles, customer access and SSO through your identity provider.
- We test ticket creation, assignment, customer replies and ERPNext customer linking in a staging site.
- We document each customization so future upgrades can be reviewed against a known baseline.
How we hand over
- You receive the written configuration, bench and image build files, and access notes for your team.
- We run a cutover checklist covering data sync, email routing and rollback steps before go-live.
- We train support leads on daily queue handling, SLA views and escalation to ERPNext records.
- We provide runbooks for updating Helpdesk and ERPNext together on the same bench.
How we support
- Post-go-live support, upgrades and continuous testing are available as a retainer.
- We review each Frappe and ERPNext minor release against your custom Helpdesk settings before rollout.
- We confirm Frappe version support status with you so warranty coverage questions are settled early.
- We keep backup and restore checks for the shared bench in scope when you ask for them.
