Every internal request, from IT to quality, from administrative services to the technical team, and every external customer support case runs through a single ticketing system with coded references (TLP-2026-0001), a proper state machine and a full audit trail, rather than getting lost in email and WhatsApp. Based on its category, each request lands with the right department, is claimed from a pool or assigned, started, resolved, verified and closed. Every step is written to an append-only activity log; who did what, when and why is never lost. This is an ITSM/help desk layer, an area your ERP simply does not touch.
Logo, Mikro, SAP, Netsis or Uyumsoft do not model a request lifecycle (opened → assigned → resolved → verified → closed), reopening, the separation between an internal note and a reply visible to the requester, SLA/deadline tracking, or the redirection of a request to another department where it returns to a pool. These are ITSM/help desk needs that fall outside ERP scope. Forcing the ERP into this behaviour through customisation runs against its architecture and carries an unbearable cost, which is why most companies end up losing requests in Excel and email. The portal adds this layer without touching the ERP; the ERP remains the single source of truth.
Each department has its own categories (e.g. IT: Hardware / Software / Network). When a request is opened, a category is selected and it lands with the right department. Every department has an 'Other' fallback category; when a request is redirected to another department, its category is automatically mapped to the target's 'Other' category.
An open request waits in the department pool. A department member claims it, a manager assigns it to a specific person, and the assignee can transfer it to someone else within the same department with a stated reason. Every move generates a notification and is recorded.
A request that landed with the wrong department is redirected by a manager to the correct one with a documented reason. The request returns to the pool (open) in the target department, its assignment is reset, and its category is mapped to the target's fallback category. The redirection reason is stored in the activity log.
The main path runs open → assigned → in_progress → resolved → closed, with a reasoned rejection or cancellation from open/assigned and reopening from resolved. Every transition passes through a state guard within a single transaction; a stale screen or a concurrent operation cannot force an invalid transition. Closed, rejected or cancelled requests are terminal and accept no further action.
The assignee marks the request 'resolved' with a resolution note; the authority to close it rests with the requester. The requester approves and closes the resolution, or reopens it with a reason (resolved → in_progress, keeping the assignee). Resolved requests left pending for a defined number of days are closed automatically via cron.
Comments can be internal (is_internal) or public. Internal notes are visible only to members of the target department and to managers; they are never sent to the requester. Files attached to an internal comment are likewise hidden from the requester. The team can talk freely among themselves, while the requester sees only the replies intended for them.
Opening, claiming, assigning, transferring, redirecting, starting, resolving, closing, reopening, rejecting and cancelling — every action is written to an immutable activity log. Rejection, cancellation and redirection reasons, along with transfer targets, are stored in the record's metadata. The question of 'who, when and why' can always be answered.
Each request is given a priority (low/normal/high/urgent) and a deadline (due_date). Requests are tracked by priority and deadline; overdue and upcoming ones are surfaced. Role-based views — 'assigned to me / department pool / opened by me' — make workload easy to follow.
The same infrastructure also runs as an outward-facing support desk: records tied to company and product, support category/type, notification email, and assignment and reply flows. Internal work requests and external customer support cases are managed within one disciplined model.
An employee (or customer) opens a request with a title, description, target department, category, priority and, where applicable, a deadline, and attaches files. The request receives a unique code (e.g. TLP-2026-0001) and the managers of the target department are notified.
The request lands in the department pool. A member claims it, or a manager assigns it to someone. If it reached the wrong department, it is redirected to the correct one with a reason and returns to the pool there.
The assignee starts the request (in_progress), progresses within the team through internal notes, and transfers it within the same department if needed. Once the work is done, it is marked 'resolved' with a resolution note and the requester is informed.
The requester approves the resolution and closes it, or reopens it with a reason. If no approval comes, the system closes the request automatically after the defined number of days. Every step is recorded in the audit trail.
At its core, Requests & Help Desk is a pure intranet/ITSM layer; there is no equivalent object in the ERP and it does not depend on the ERP to operate. Its relationship with the ERP is built on being fed master data (personnel, departments, organisation) and on linking request outcomes to the relevant operational modules.
Requesters, assignees, managers and the department hierarchy are fed by personnel and organisation data mirrored read-only from the ERP/HR module. Department manager definitions and memberships come from this master data; you do not maintain a separate user list.
If a request triggers an expense, a maintenance work order, a purchase request or an asset transfer, it is linked to the relevant module; steps that require approval are handed to the central Approval Engine. Request records thus merge with other portal processes in one auditable flow.
The ticket lifecycle runs entirely in the portal; there is no obligation to write back to the ERP. The ERP remains the single source of truth, and the portal never alters it for this ITSM need. If desired, a summary of resolved requests can be blended with ERP data in the reporting layer.
Tell us your ERP and your process. We’ll show how this module works and scope it into your subscription — no man-day, licence or setup fee.
Book a Demo →