Customer Support Portal

The Customer Support Portal is a self-service website you can open up to your customers, branded per company and reached at a web address of your choosing. It's a separate, lightweight experience from the workspace your team works in — fast to load, comfortable on a phone, and designed so a customer never touches your team's tools. Signing in there opens onto that one company's portal and nothing else.

Once inside, customers can browse and track their own requests, follow the conversation on each one, reply with attachments, and submit new requests — see Inside the portal below.

How your customers sign in

Sign-in is passwordless — there are no passwords to create, forget, or reset. A customer proves who they are with their email address and a one-time link or code, and that's it.

1. They open your portal and enter their email address.
2. DevStride emails them both a one-time link and a 6-digit code.
3. They either click the link or type the code back into the portal.
4. They're signed in, and their session lasts about a week before they're asked to sign in again.

Opened the wrong company's portal? If a requester already belongs to another company, DevStride can email them directions to their own company's portal. This guidance email contains no sign-in code or one-time login link; they still sign in at the correct portal. It does not move their account or give them access to another company. The on-screen confirmation stays the same to protect customer privacy.

Sign-in email limits. Each mailbox has an allowance of three login emails per clock hour within your organization. Requests refused before a login is approved do not use that allowance. Wrong-portal guidance emails have their own allowance of three per clock hour, so requesting directions does not use up the emails needed to sign in at the correct portal. Repeated requests from the same IP address are still limited, including refused requests.

Why passwordless sign-in is safe

Opening a portal to the outside world raises fair questions about security. Here's what protects it, in plain terms:

• No way to fish for who has access. When someone enters an email, they always see the same friendly confirmation — whether or not that address is allowed in. A stranger can't use the portal to discover who your customers are, or even whether a given person is one of them.
• Links and codes expire quickly. A sign-in link or code only works for about 15 minutes after it's sent, and a code stops working after several wrong tries. An old email sitting in an inbox can't be used to get in later.
• Sessions don't last forever. A signed-in session expires after about a week, so an unattended device doesn't stay signed in indefinitely.
• Access is cut off the moment you revoke it. The portal re-checks access on every visit. If you block a requester, erase them, remove them from their company, or disable Service Desk, their access ends immediately — you don't have to wait for their session to run out.
• A separate door. A customer signed in to the portal is a portal-only identity. It reaches that one company's portal and nothing else — never your team's workspace, boards, or internal notes. And each company's portal keeps its own sign-in state: being signed in to one portal never carries over to another company's portal, even in the same browser.

Who can sign in: access modes

Each company decides who is allowed to sign in to its portal. You choose one of three access modes on the company record:

Pick the mode that matches how open you want each customer's portal to be — wide open for a public-facing desk, domain-restricted to keep it to a customer's own staff, or invite only for a tightly controlled account.

Branding the portal for each company

A company's portal can wear that customer's look rather than a generic one. On the company record you can set:

• a logo — upload an image file for DevStride to store and serve, or link one by URL if it's already hosted somewhere,
• header text to greet them,
• a primary color for buttons and accents.

Set none of these and the portal falls back to a neutral DevStride-branded shell — so every company has a clean, presentable portal from day one, and you dress it up only where it's worth doing. A small "Powered by DevStride" note sits in the footer.

Portal language

The portal automatically detects the visitor's language from their browser, so a customer sees it in whatever language their device prefers. You can also set a Default language on the company record to pin the portal to a specific language when you'd rather not rely on the browser.

Where you configure all this

Everything above — the portal's web address, its access mode, its branding, and its default language — lives on the company record, under Service Desk → Companies. Open a company, and you'll find its portal settings alongside the per-company defaults you already manage there. A Preview portal link on the company opens its portal in a new tab, so you can check what you've set exactly as your customers will see it.

Two permissions come into play:

• Manage Requesters — configure a company's portal: its web address, access mode, branding, and default language. This is the same permission that lets you manage requesters and companies.
• Manage Service Desk Settings — enable Service Desk in the first place (the portal only exists once the desk is on). See Enabling Service Desk.

See Permissions for how these roles fit together, and Requesters & Companies for managing the customers who'll be signing in.

Inside the portal: requests, conversations, and submissions

Signing in lands a customer on My Requests — a list of every request they've raised with you, with a search box and a status filter so a customer with a long history can find the one they mean. Each row shows the request's title and where it stands in plain customer-facing terms, so "is anyone looking at this?" is answered without opening a single ticket.

Following a request

Opening a request shows its conversation — the same public thread your team maintains from the ticket, with your agents' public replies and the customer's own messages in one place. A status chip at the top (for example Awaiting your reply) tells the customer at a glance whether the next move is theirs or yours, and it stays in step with the thread as replies land. If a customer replies to one of your team directly and that colleague forwards the reply in, it appears here as the customer's own message too, so the thread they see stays complete.

From the conversation a customer can:

• Reply — their message lands on the ticket for your team, exactly like a reply by email would.
• Attach files — every uploaded file is automatically scanned for malware before your team ever sees it; a file that fails the scan is discarded and never reaches the ticket.
• Update request details — if you've exposed fields to customers on the request's form, the customer can fill in or correct those details right from the portal. Fields your team keeps internal never appear.
• Mark the request solved — when their problem is sorted, the customer can close the loop themselves rather than leaving the ticket to age out.

Submitting a new request

The portal's Submit request page lists the request forms you've chosen to publish there, so a signed-in customer can raise a new request without leaving the portal — no email required, and the submission files itself exactly as a form submission always does. You control which forms appear: listing a form in the portal is a per-form setting, and any enabled form can be listed — public or private, file-upload fields included. See Request Forms for how to publish one.

Browsing the Help center

The portal's Help center puts your published knowledge-base articles in front of customers so they can answer their own question instead of raising a request. A signed-in customer reaches it from the Help center link on My requests, then browses by category or searches.

They see only the articles you have pointed at them — published, marked for the portal, not inside an internal-only category, and shared with their company. Everything else is simply absent.

The same articles are searched while a customer is submitting a request: as they describe the problem, matching articles appear under "These articles may help". This is where a knowledge base earns its keep — a customer who finds the answer there never files the ticket.

See the Knowledge Base section for writing and publishing articles, and The customer Help center for exactly what customers experience.

Published lists

Alongside their own requests, a customer can be given published lists — a set of work items you have chosen to share with them. A list might be the roadmap items their account is waiting on, or the open defects affecting them.

A published list renders as a proper table: number, title, status, and dates, so a customer can scan it the way you would scan an items view rather than reading down a column of titles. Selecting any row opens a detail drawer for that item, and the drawer has its own URL — so a customer can link a colleague straight to the item in question instead of saying "third one down". The list keeps the order you gave it.

Visibility is per company, not per portal: a published list is visible only to portal users whose company holds that list's grant. A customer who has not been granted a list does not see it at all — not an empty table, not a locked row.