Service Desk

Requesters & Companies

Requesters are the customers who raise tickets; companies group them. Manage their details, set per-company defaults, merge duplicates, and handle erasure requests.

When a customer emails your support address, DevStride records them as a requester — the person on the other side of the conversation. Requesters can be grouped into companies, the customer organizations they belong to. Both are managed from the Service Desk module.

Requesters never use a seat

A requester is an outside identity, not a member of your organization. They can sign in to your customer support portal, but never to your workspace — and they hold no role and never consume a paid seat, no matter how many tickets they raise. You only pay for your own team.

Requesters

Open Service Desk → Requesters for a directory of everyone who has contacted your team. The table shows Name, Email, Status, and Company.

A requester is created automatically the first time someone new emails in; you rarely add one by hand. Click a row to open the requester's detail, where you can edit their name, see their recent requests, and set their status.

The Requesters tab listing requesters with their name, email, status, and company.

Status: Active vs. Blocked

Active — the normal state; their email creates and continues tickets.
Blocked — use this for an abusive or spammy sender. Mail from a blocked requester is held out of your Inbox.

Merging duplicate requesters

The same person sometimes writes from two addresses (a work and a personal account, say), creating two requesters. Open a requester and choose Merge to fold one into the other. Their tickets and history combine under a single requester, so you see one continuous relationship instead of two fragments.

Erasing a requester (privacy requests)

When a customer invokes their right to be forgotten, open the requester and choose Anonymize. This permanently scrubs their personal details — name, email, phone, and the like — from DevStride, and reaches everywhere else those details were kept: the original content of the emails they sent (held in storage behind each ticket), their personal information inside notifications and activity history, and their portal sign-in. If they had access to your support portal, that access is revoked on the spot.

The tickets your team worked are kept but de-identified, so your history and reporting stay intact — you satisfy the erasure request without deleting the work. And the erasure holds: if the same person emails in again later, DevStride won't quietly re-create or re-identify the requester you anonymized.

Anonymizing is permanent

Erasing a requester can't be undone. Use it deliberately, for genuine privacy requests — not for everyday cleanup. To tidy duplicates, Merge instead.

Companies

Open Service Desk → Companies to manage the customer organizations your requesters belong to. A company groups all of a customer's people and lets you set defaults that apply to every request they send.

The Companies tab in the Service Desk module, with the New company button.

Auto-matching by email domain

Give a company one or more email domains (for example acme.com) and DevStride automatically links new requesters to it when their email matches. New people from a known customer slot into the right company with no manual step. And when you first create the company, any existing requesters already on that domain are linked to it right away — so setting up a company retroactively gathers the customers you've already been talking to, not just future ones.

When adding domains in the company dialog, pressing Enter or Tab — or simply clicking away from the field — commits the domain you're typing. Domains are stored lowercase, so capitalization never creates a duplicate.

Per-company defaults

A company can carry its own defaults that override the channel address for its requests:

Default location — file this company's tickets under their own workstream or item, instead of the channel address's default. (See the override rules.)
Default assignee and watchers — route this company's tickets to a specific owner and notify specific people, on top of (and taking precedence over) the channel address defaults.

These defaults are what make per-customer handling effortless: set them once on the company, and every future request from that customer is filed and routed your way automatically.

Why group requesters into companies

Beyond defaults, a company gives you a single view of everything a customer has asked for — useful for spotting a customer who's been in touch a lot, or for reviewing an account before a renewal conversation.

Portal settings

A company also carries its customer-portal configuration — the portal's web address (its Portal slug), who's allowed to sign in (the access mode: Open, Domain-restricted, or Invite only), branding (a logo you upload or link by URL, header text, and a primary color), and the default language customers see. Set these on the company record alongside its other defaults, and use the Preview portal link to open that company's portal in a new tab and see it exactly as its customers will.

For the full walkthrough — how the portal looks to your customers, how passwordless sign-in works, and what each access mode allows — see the Customer Support Portal page.

Email Channels & Setup

Create a support address, forward your inbox to it, and choose where new tickets land. Plus how replies are threaded, and exactly what happens when you remove a channel.

Customer Support Portal

A branded, passwordless self-service portal your customers reach at a per-company web address — how sign-in works, why it's safe, and how to brand and control access for each company.