Release Notes

2026-09-01

Forward a customer's email to your support address and the ticket opens in their name — their subject, their acknowledgement, their reply thread. Plus convert any item into a ticket, published lists as a real table, and scanned attachments on public request forms.

📧 Forward it in, and the ticket belongs to the customer

Your customers email people, not addresses — the founder who onboarded them, the CSR they trust. Forwarding that mail to your support address used to make the record worse rather than better: the ticket opened in your colleague's name, their covering note stood in as the customer's own words, and the acknowledgement went back to your own employee. Now DevStride reads the original out of the forward and opens the ticket in the customer's name.

  • They become the requester — their subject, their company, and the acknowledgement sent to their own address, so their reply threads back onto the ticket. Your colleague stays on as a watcher, their covering note kept internal. 📚 Email channels
  • Forwarded replies post as the customer, re-arming the response clock and firing your automations exactly as a direct reply would.
  • From there it is an ordinary ticket — Inbox, routing, SLA, automations, the portal.
  • Where DevStride cannot be certain, it credits nobody rather than the wrong person. A forward it cannot authenticate — check your own domain's DMARC record first — or one bundling two originals still opens a ticket, owned by the colleague who sent it, with the text kept internal. 📚 When a forward is credited

On for every organization with a Service Desk email address; nothing to switch on.

🎫 Also new in Service Desk

  • Convert any item into a ticket. Attach a customer to work you already have — it keeps its number, board, history and links, and gains the Inbox, the portal and the customer/internal split. Needs Manage Requesters; cannot be undone. 📚 Turning an existing item into a ticket
  • One unified description, when the split is not worth it. A ticket's description control now reads Internal / Customer / Unified. Choose Unified and there is a single description, shown to your team and the customer alike, sanitized and kept in step. Tickets start on the split, and the control appears only on tickets — an ordinary work item has no customer to show one to. 📚 The two descriptions
  • Published lists are a real table, with a detail panel on every row that has its own shareable link. 📚 Published lists
  • Row order no longer leaks your internal ranking. Lists hid the customer rank field but were still ordered by it, so the ranking you had chosen not to show was readable as position. Rows now order by last updated, or by your saved view's own sort.
  • Files on a public request form are scanned before anyone can open them, replacing an unscanned upload straight into public storage. New limits come with it: 25 MB per file, 20 files per submission, and a fixed list of permitted types. 📚 Request forms
  • "Capture requester" is now "Create as Service Desk ticket", with a Ticket badge on the forms list — and staff can now actually submit a private ticket-intake form on a customer's behalf.
  • A colleague's address cannot be erased as though it were a customer's. Anonymize and Merge refuse an address belonging to an active member, because erasure works by address and that one also appears on other people's tickets. 📚 When an address belongs to your own team

🐛 Also fixed

  • New GitHub branch events with long or accented branch names no longer stop linking to their item
  • A multi-file upload no longer discards the files that succeeded when one of them fails, or leaves the field spinning
  • Bulk and background item updates can no longer roll back a ticket's requester, SLA clock or verification state
  • Description attachments no longer fail to register when an item's asset-group name or position is already taken
  • A hard-bounced internal notification no longer switches off a colleague's ticket email