Google access requests
Sometimes people show up at the door before you've invited them. A new hire at a client hears "we have a monitoring portal" and tries to sign in; a manager forwards the portal address to a colleague. When someone signs in at {workspace}.upall.app with Google and no account with that email exists in your workspace, UpAll doesn't turn them away — and doesn't let them in either. It records an access request and shows them that their request is awaiting approval.
Nothing has been granted at that point. The person sees no monitors, no clients, no data — just a "request received" screen. What your team gets is a decision to make.
The pending queue
In the console, open Access requests. Each row is one person who tried to get in: their name and email as Google reports them, when they asked, and the request's status — pending, approved, or rejected. Because the sign-in went through Google, the email on the request is verified; you're deciding about a real, confirmed identity, not a typed-in address.
Approving
Approve asks you one question: which client does this person belong to? Pick the client from the list and confirm. UpAll creates their portal account attached to that client, and the next time they sign in with Google they land in that client's portal — read-only, scoped to that client's sites and incidents, like every client user.
The client assignment is the decision that matters, so treat the email domain as a hint, not proof — confirm with your contact at the client that the person is theirs before approving. Approval doesn't send a notification, so let the person know they can sign in again.
Rejecting
Reject closes the request without creating anything. Use it for addresses you don't recognize, or requests you can't tie to any client. Rejecting isn't a ban — if it later turns out the person was legitimate, the clean path is to send them a proper invite link locked to their email.
Why this beats sharing passwords
The traditional way client staff get into a portal is the worst way: one shared login, passed around by chat message, known by people who left the company two years ago. Access requests replace that with a flow where:
- Every person is their own account. Each viewer of the portal is an individual with a verified Google identity — no communal credential to leak.
- Nothing is granted by default. An unknown sign-in produces a pending request, not access. The default answer is "not yet".
- A human assigns the scope. Someone on your staff explicitly decides which client the person belongs to — the one decision a computer shouldn't guess from an email domain.
- Offboarding is per-person. When someone leaves the client, you remove their account; nobody else's access changes and no password needs rotating.
Invite or wait for a request?
Both paths end in the same kind of account. Use an invite when you're driving — onboarding a client, adding a known person. The request queue covers the opposite direction: when word of the portal spreads on its own, everyone it reaches arrives as a pending decision rather than a surprise account.