Client portal

The client portal is the customer-facing half of GVenta Help Desk: a fully separate experience with its own authentication, its own sidebar (My Tickets, Knowledge Base, Create Ticket) and its own branding. The logo, company name and colors shown to customers are configured independently of the staff interface under Settings → Look & Feel (see Settings).

Customer contacts are a completely separate identity system from staff users. A contact is always scoped to a single company, every portal query is filtered by that company, and an attempt to reach another company’s data is recorded in the audit trail as an unauthorized_access event and answered with a generic 404, so the portal never confirms that another company’s ticket exists.

Signing in and creating an account

The portal entry page at https://your-instance.example/clientarea is a two-column layout with a branded logo pane and a tabbed form pane.

Sign In asks for email, password and a “remember me” option, with error and success messaging. Contact accounts include brute-force protection: failed sign-in attempts are counted and the account can be temporarily locked. If you open the portal in a second browser tab, or your short-lived token expires while your session is still valid, the portal falls back to the session rather than signing you out.

Create Account asks for full name, email, an optional ticket number, password and confirmation. There are two registration paths.

Registering with a ticket number

Possession of a ticket reference proves identity. The application checks that:

• the ticket number matches the TICK-YYYYMMDD-NNNN format,
• the ticket exists, and
• the email address you entered matches the ticket’s requester exactly.

If all three pass, the account activates instantly.

Registering without a ticket number

Mailbox ownership is proven by an emailed activation link. No unverified password is ever stored: you choose your password on the activation page, after the email address has been proven. The registration request always returns the same generic message whether or not the address is already known, so the form cannot be used to discover which addresses have accounts.

Claiming an existing contact

Many customers already exist in the Help Desk before they ever visit the portal, because the email pipeline creates contact records automatically from inbound mail. If a contact record already exists but has never been given portal access, registration claims that record and links it to its existing ticket history instead of creating a duplicate.

How your company is resolved

When you register, the application works out which company you belong to in a fixed order:

1. Use the customer on the ticket you supplied, if any.
2. Otherwise, match your email domain to an existing customer.
3. Otherwise, create a new customer from the domain.

Whichever step succeeds, the ticket is back-filled so it is correctly linked to that company from then on.

Arriving from a ticket link

If you reached the registration page by following a link in a ticket email, a hint banner tells you which email address to use, so you do not guess wrong and fail the exact-match check.

Why it matters: Customers who have only ever emailed you can self-serve a portal account in seconds, and their entire past conversation history is already there waiting for them.

My Tickets

After signing in you land on https://your-instance.example/client/dashboard, which shows:

• A personalized welcome header.
• Three stat cards: Open, Pending and Resolved.
• A Recent Tickets list with a New Ticket button.

Creating a ticket

The Create a Ticket drawer is resizable and remembers its width. It contains:

Field	Notes
Subject	Required, 255 characters maximum
Priority	Low / Medium / High / Urgent
Description	Required
Attachments	Multi-file, via a drag-and-drop area with a live file list

Reading and replying

Clicking a ticket opens a resizable ticket drawer showing the subject, its metadata, the full conversation and a reply composer with its own multi-file attachment area. Attachments on any message can be viewed inline or downloaded.

What happens behind the scenes

The rules below are enforced on the server, not in the browser.

• Internal notes never reach the customer. Staff-only notes are stripped from the conversation before it is returned to the portal. They are not hidden by the page; they are never sent, so they cannot be revealed through developer tools.
• Company ownership is re-verified on every read and every reply. If a ticket’s company does not match the signed-in contact’s company, the attempt is audit-logged and answered with a generic 404.
• Portal tickets take the same creation path as email tickets. They get the same ticket number format, the same business-hours SLA deadlines, the same source color band and the same downstream behavior. Staff cannot tell a portal ticket from an email ticket, by design.
• Your priority is a suggestion. The support desk decides real urgency. An unrecognized priority value falls back to Medium rather than producing an error, so a bad value can never stop someone raising a ticket.
• Replying to a pending ticket reopens it. A ticket in pending status is waiting on the customer, so your reply automatically flips it back to open.
• Closed tickets refuse replies with a clear message.
• The assigned agent is told. If the ticket has an assigned agent, that agent receives a reply_received notification email. Whoever performed the action is always excluded from their own notification.
• A failed attachment never loses a ticket. Attachment failures are logged and swallowed, so the ticket you just raised is saved even if a file upload fails.
• Staff are alerted the same way regardless of channel. The same admin notification that fires for inbound email fires for portal tickets.

Knowledge base

The portal knowledge base at https://your-instance.example/client/kb opens with a “How can we help?” hero and a prominent search box, followed by:

• A category grid showing only categories that are visible and contain at least one article you are allowed to read.
• A search results panel with a clear-search control.
• A category article listing with a back control.
• An article reader whose back navigation returns you to wherever you came from.

Behind the scenes, the client knowledge base only ever returns articles with status published and visibility public or company, and only from categories that are either public or explicitly assigned to your company. Every one of these constraints lives in the database query itself, not in the page. See Knowledge base for how staff set visibility.

Password recovery

https://your-instance.example/client/forgot-password and /client/reset-password provide a standard request-and-reset flow using expiring, single-use tokens. The same pages serve the “activate your new account” step of the no-ticket-number registration path.

Ticket permalinks

Every notification email contains a direct link to its ticket in the form https://your-instance.example/tickets/TICK-YYYYMMDD-NNNN. Visiting one:

• Redirects you to the client login page if you are not signed in, with the full destination preserved as a redirect parameter, so you land on the right ticket after signing in.
• Shows a branded 404 page if the ticket number does not exist.
• Shows a branded 403 “Access Denied” page if the ticket belongs to a different company. The page names the account you are currently signed in as and offers Switch Account and My Tickets links.
• Otherwise opens the ticket.

The older /client/tickets URL is permanently redirected to the new route, preserving the ticket ID, rather than being retired. That URL is live in notification emails that were sent before the change.

Why it matters: Links in emails you sent two years ago still work.

Portal endpoints

Everything the portal does is available through the client-scoped part of the REST API, so a customer’s own systems can raise and follow tickets programmatically. See the client portal group of the endpoint reference, and the client login and ticket-creation walkthrough in API examples.