Core concepts

This page defines the terms you will meet everywhere in GVenta Help Desk, in the interface and in the API. Where the interface shows a friendly label and the API uses a code value, both are listed.

Ticket status

A ticket moves through a six-state workflow.

Interface label	API value	Notes
Open	open	The default state for new work. Shown as a Kanban column.
In Progress	in_progress	Work that an agent is actively handling. Shown as a Kanban column.
Pending	pending	Waiting on the customer. When a customer replies to a pending ticket through the client portal, it flips back to Open automatically. Shown as a Kanban column.
On Hold	on_hold	Paused work.
Resolved	resolved	The issue has been dealt with. Shown as a Kanban column.
Closed	closed	Finished. Customers cannot reply to a closed ticket from the portal.

The Tickets page filters to Open, In Progress and Pending by default, which is the working queue. Resolved and Closed tickets count as “closed work” in dashboard panels and reports.

Ticket priority

Interface label	API value
Low	low
Medium	medium
High	high
Urgent	urgent

Priority drives the SLA targets described in SLA engine. When a ticket is created from an email, the email’s importance flag sets the priority: high importance becomes High, low importance becomes Low, and everything else becomes Medium. When a customer picks a priority in the client portal it is treated as a suggestion, and an unrecognized value falls back to Medium rather than blocking the ticket.

Message type

Every entry in a ticket’s conversation thread has a type.

API value	Meaning
customer_reply	A message from the customer, whether it arrived by email or through the portal.
agent_reply	A reply from a member of staff that is emailed to the customer.
internal_note	A note for staff only. It is recorded on the ticket, visually flagged, and never emailed.
system	A message generated by the application.

Internal notes versus replies

The reply composer has two send paths. Send Reply records an agent reply and emails it to the customer, with any attachments included in the email itself. Internal Note records the text on the ticket for your colleagues and never sends anything. Internal notes are stripped on the server before a conversation is returned to the client portal, so they are never sent to a customer’s browser at all. See Tickets for the composer.

Staff roles

Interface label	API value
Super Admin	super_admin
Agent	agent
Viewer	viewer
KB Editor	kb_editor

Each role carries an explicit permission set. See Roles and access control for the full lists.

Knowledge base article status and visibility

Articles have a lifecycle and a visibility level.

Field	Values
Status	draft, published, archived
Visibility	public, internal, restricted, company

In the article editor the visibility choices are presented as Public, Internal (Staff Only) and Company Specific, the last with a picker for which companies may read the article. The client portal only ever returns articles that are published and either public or company, and only from categories that are public or explicitly assigned to the signed-in contact’s company. The restricted value is available through the API. Categories have their own visibility too: either public or limited to a chosen set of customers. See Knowledge base.

Email source types and outgoing providers

Receiving and sending are configured separately.

Field	Values	Interface label
Email source type (inbound mailbox)	microsoft365, imap	Microsoft 365, IMAP
Outgoing provider (sending)	microsoft365, sendgrid	Microsoft 365, GVenta (SendGrid)

You can monitor several inbound mailboxes at once. Only one outgoing configuration is active at a time. Both are set up under Settings, Email Integration; see Settings and administration.

Ticket numbers

Every ticket gets a number in the form TICK-YYYYMMDD-NNNN: the date it was created followed by a daily sequence. This format makes every reference human-readable, sortable, and instantly recognizable in an email subject line. The Help Desk relies on it in several places:

• Outgoing replies carry the number in the subject, as RE: [TICK-YYYYMMDD-NNNN] Original Subject, so customers can always see which ticket a message belongs to.
• Inbound email is matched back to its ticket by conversation and message identifiers first, and by the ticket number in the subject as a fallback. When the subject match is used, the sender’s address must also match the ticket’s requester, so one customer cannot reply into another customer’s ticket by quoting its number.
• A customer can register for the client portal using a ticket number as proof of identity, provided their email address matches the ticket’s requester exactly.
• Every notification email links to the ticket at https://your-instance.example/tickets/TICK-YYYYMMDD-NNNN.

Ticket sources

A ticket’s source records which channel it arrived through. Tickets created from email take their source from the mailbox they arrived in, and each mailbox has a color that appears as a band on ticket cards. Tickets created through the API or the client portal carry a channel label such as Phone, Storefront, or the name of a partner system.

Administrators maintain this vocabulary under Settings, Ticket Sources, where labels can be added, renamed, recolored and removed. An unknown source value arriving through the API auto-registers on first use, so an integration can report its own channel without anyone creating it in advance. Sources appear as a filter in reports and as a distribution chart on the Overview tab.

Two identity systems

GVenta Help Desk keeps two entirely separate kinds of account that never overlap. Staff identities are the people (and AI agents) on your team, each with a role, who sign in at /admin. Client identities are your customers’ contacts, who sign in at /clientarea, receive tokens marked as client tokens, and are scoped to a single company so that every portal query is filtered to that company’s data. The details, including what happens on a cross-company access attempt, are in Roles and access control.

Why it matters: A shared vocabulary between the interface, the API and the reports means a filter you build on screen, a query an integration sends, and a figure in a CSV export all mean exactly the same thing.