Service Desk

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.

A channel address is the email address customers' messages arrive at. You create one in DevStride, then forward your real support inbox (for example support@yourcompany.com) to it. From then on, every email becomes a ticket — and every reply you send goes back to the customer over email.

Creating a channel address

  1. Open Settings → Service Desk → Channel Addresses.
  2. Click + Channel.
  3. Fill in the New channel address dialog (fields below) and save.

The fields

FieldWhat it does
Address (required)The local part of your DevStride inbound address — you type the part before the @, and DevStride appends its inbound domain (for example acme-support@in.devstride.com). Lowercase letters, numbers, dots, and hyphens only.
Default location (required)The workstream, folder, or item where new tickets from this address are filed. Think of it as the bucket the address drops work into.
Default work type (required)The work type new tickets are created as (for example a Support Request type).
Default request form (optional)Applies a request form's field set to tickets from this address. Choose No form to skip.
Notify on new ticket (optional)A default assignee, plus watcher users and teams, applied automatically to every new ticket from this address — so the right people are notified without setting up an automation.

Editing an address

Click the pencil icon on a row to change its defaults. You can change the location, work type, form, or notification targets at any time.

The address itself is fixed once created — it can't be renamed, because mail is already routed to it. Changes to the defaults apply to future tickets only; tickets already created keep the values they were filed with.

How email is matched to a conversation

You don't have to manage threading — DevStride figures out whether an incoming email is a brand-new request or a reply to an existing ticket, and routes it accordingly:

  • A new message creates a new ticket. The email's subject becomes the ticket title, the body becomes the ticket's Customer description, the sender becomes (or is matched to) a requester, and your Notify on new ticket defaults are applied.
  • A reply is added to the same ticket as a new comment, keeping the whole conversation in one place. DevStride recognizes replies from the email's threading information, so a customer simply replying in their mail client lands on the right ticket.

When you send a Reply to customer from a ticket, DevStride emails it to the requester and threads it so their next reply comes back to the same ticket. Quoted "On such-and-such date you wrote…" trails are stripped automatically, so each comment shows only the new message — not a growing pile of quoted history. (See Working a Ticket.)

Removing a channel address

Click the x icon on a row and confirm in the dialog:

Remove ? Inbound email to this address will stop creating tickets. Existing tickets are unaffected.

Removing an address does exactly that and no more:

  • New mail to that address stops becoming tickets. Routing for the address is shut off immediately.
  • Existing tickets, conversations, and requesters are untouched. Nothing already created is deleted or changed.
  • Late-arriving mail is safely dropped. If a message trickles in to a just-removed address, DevStride discards it cleanly — it won't create a stray ticket or a phantom requester.

Where a ticket actually lands: location overrides

The Default location on the channel address is the baseline destination. One thing can override it: a company default location.

If the requester belongs to a Company that has its own default location set, new tickets from that company are filed there instead — handy when you want each customer's requests grouped under their own workstream. The address's default work type is always used either way; a company override only changes the where, not the what.

If a company's override points at a workstream or item that has since been archived or deleted, DevStride quietly falls back to the channel address's default location, so a request is never lost.