Submitting your first request and picking the right topic

It is Tuesday morning. A new hire starts Thursday, the finance lead cannot reach a shared mailbox, and someone forwarded you an email that looks like phishing but might not be. Three different problems, three different teams, and one of you to sort them out. You open the support portal, see a form, and pause on the first field: a dropdown asking what this request is about.

That pause matters more than it looks. The topic you pick is not a label for filing later. It is the switch that decides who reads your request first. Choose well and the right person opens it within minutes. Choose vaguely and your request sits in a general queue while someone figures out where it belongs, then hands it off, then waits for the next person to pick it up. The work is the same either way. The clock is not.

A small team does not have spare hours to lose at the handoff. So the fastest thing you can do is also the simplest: name the request accurately on the way in. Here is how to do that without overthinking it.

Anyone can submit a request without signing in. The form works whether you are logged in or not, so a contractor or a colleague who has never touched the portal can still reach the team.

Signing in first does two useful things. It auto-fills your name and email so you are not retyping them, and it tags your request as a verified identity, which lets the team act on sensitive items (access changes, account questions) without a separate round of confirming who you are. For anything touching permissions or security, that verification saves a step. For a quick question, signing out is fine.

Every topic on the form maps to a specific group inside Cloud Sentry. Picking the closest match is what sends your request to people who already know that kind of work. A few common ones, drawn straight from the submit a request guide in the knowledge base:

• IT Support for laptops, network, printers, multi-factor authentication, software, and license questions, including seat additions and renewals.
• Joiners and Leavers for onboarding a new hire or offboarding someone leaving. File this at least one business day ahead so accounts are ready on day one.
• Reporting a Security Concern for suspected phishing, a compromised account, or anything that feels off. Use it even when you are not sure; flagging early is always the right call.
• Request Access for a system, shared mailbox, or folder you cannot reach.
• Compliance and Audit Support for SOC 2, HIPAA, or customer security questionnaires.

If none fit cleanly, pick the nearest one and explain in the description. The team will route it. The goal is a good-enough match, not a perfect one.

The topic gets your request to the right desk. The description decides how many rounds it takes to resolve. The strongest ones answer four questions before anyone has to ask:

1. What you were trying to do, in plain language.
2. What you observed, including any error message copied word for word.
3. When it started, and whether anyone else is affected.
4. What you have already tried, so nobody repeats steps you have run.

Screenshots, log snippets, and short screen recordings help more than another paragraph of prose. You can attach files directly on the form.

Urgency tells the team where your request sits in the queue. It is not a rating of how hard the problem is. Set Low for a question or a minor annoyance, Medium when something slows you down but you have a workaround, High when you or your team are blocked, and Critical for anything business-stopping or a security incident in progress. For Critical items, call in addition to filing, so the clock starts immediately.

You land on a confirmation page with a request ID. If you were signed in, the request also appears under My Requests, and you get email updates as the status changes. The tracking your requests guide explains what each status means, so you always know who owes the next move.

That first dropdown is the whole point. A small team wins by spending its attention where the work is, not on chasing requests through the wrong queue. Naming a request well is a 30-second habit that hands the routing back to the system and keeps you out of the middle of it. The next time you open the form with three unrelated problems and one of you, the only question left is which one you file first. So which one would it be?