It is 4:45 on a Friday. A sales lead at Northwind Logistics just messaged you (the one person who keeps the company's accounts running) to say they are locked out of their email and have a customer call in 15 minutes. You open a ticket with your managed partner, type out the problem, and hit send. Then the reply comes back: who are you, which account, and can you confirm you are allowed to ask for a password reset on someone else's mailbox?
Now you are answering questions when you should be fixing the problem. The clock is still running. The sales lead is still locked out.
That back-and-forth is the part of support that quietly eats your week. The work itself is fine; the friction is the proving who you are before anyone can start the work. The Cloud Sentry portal is built to skip that step. When you sign in, your request arrives already tied to a real, verified person at a known company. We can act on it in the first reply, not the third. Here is how sign-in works, and why the small act of signing in does more than you would expect.
Sign in with the identity you already have
The portal does not ask you to create a new password. You sign in with the work identity your company already runs:
- Continue with Google, if your company is on Google Workspace.
- Continue with Microsoft, if your company is on Microsoft 365 or Entra ID.
- Email me a sign-in link, if neither of those fits your address.
Pick the button that matches your work email. Google or Microsoft sends you to its own login, asks you to approve a small set of read-only permissions, and drops you back on the portal already signed in. The magic link works a little differently: we email a single-use link to the address you type, you click it from your inbox, and you land back signed in. The link is good for one use and expires after 15 minutes, so a stale link in an old email cannot let anyone in later. (See the knowledge base article on magic-link sign-in for the full walkthrough.)
There is no password for an attacker to guess and none for you to reset at 4:45 on a Friday. Your identity provider already does that work; the portal trusts it.
Why a signed-in request moves faster
This is the part that matters for the locked-out sales lead. Security is an operational problem before it is a tool problem, and identity is where that shows up first. When a request comes in from a signed-in person, three things are already true before a human reads it:
- We know who you are, confirmed by your own provider, not by a name typed into a form.
- We know which company you belong to, because your email domain maps to a known account.
- We can see your past requests, so context travels with you and nothing gets re-explained.
That verified-identity tag is what lets us act on sensitive requests, things like access changes and password resets, without a separate round of identity checks. The question "are you allowed to ask for this?" is answered the moment you sign in. A signed-out request still reaches us, and we will still help, but it starts in line behind the work of confirming you are who you say you are.
What signing in unlocks for you
Beyond speed on a single ticket, a signed-in session gives you a place to work from:
- A My Requests dashboard showing every ticket you have filed and its current status.
- Auto-filled name and email on the intake form, so you stop retyping them.
- The full knowledge base, including the explainers that sit behind the portal.
For the person running a small team, that dashboard is the difference between "I think I asked about that" and "here it is, filed Tuesday, resolved Wednesday." Nothing lives only in your memory or a buried email thread.
A few honest notes on sessions and access
Signing in is not a one-time event you can forget. The portal keeps you signed in for up to 14 days, but a session ends after 30 minutes of no activity. Come back to a tab after lunch and you may need one more click. That short idle window is deliberate: an unattended laptop should not stay a signed-in laptop for long.
A couple of edges are worth naming. If your company's Microsoft tenant requires an administrator to approve new applications, the first sign-in may need that approval before it goes through. If your email domain is not yet on your account record, the portal will not recognize you, and your account team needs to add it. Both are quick fixes, and both are documented in the knowledge base.
The point of all of it
Go back to the locked-out sales lead. With a signed-in request, the first reply is the fix, not a question about who you are. The proving step is gone because you handled it the second you signed in, and you did it with the Google or Microsoft account you already use every day. That is the whole idea: the friction that usually sits between a problem and its fix is the friction we wanted to remove.
Signing in takes one click. The minutes it saves show up every time something breaks at 4:45 on a Friday. So when the next thing breaks, what would you rather spend those minutes on: explaining who you are, or watching the problem get solved?