Managing your team, roles, and contacts in the portal

A request comes in from a Northwind Logistics manager: a new hire starts Monday and needs access to the shared drive, the finance app, and the building badge system. The person who normally handles this is out for the week. Three colleagues could pick it up, but nobody is sure who is allowed to, who Cloud Sentry will call if something is unclear, or whether the request will simply sit until Monday morning when the original owner is back at their desk.

Nothing here is broken. The request was filed correctly. The work is well understood. What is missing is a clear answer to a quieter question: who, on your side, is set up to act, and who do we reach when a decision needs a human? That answer is not a personality thing. It is a configuration. Your portal roster already holds it, whether you set it on purpose or let it default into place.

For an operations-first team, getting that configuration right is most of the battle. You are not short on capable people. You are short on a clean way to say who can do what, and who speaks for the company when it counts. Here is how the roster encodes that, and the few decisions worth making deliberately.

Every person on your roster carries one of two roles. The distinction is narrower than it sounds, and worth getting right.

An Admin can manage the roster itself. That means inviting new people, promoting a member to admin or stepping one back down, removing someone who has left, and naming who Cloud Sentry should contact. A Member can do everything that has to do with actual support work: file requests, watch their own tickets, reply on follow-ups, and act on requests shared with the team.

The thing most teams get wrong is treating admin as a status symbol. It is not. It is a set of keys to the roster. The useful test is simple:

• Will this person invite or remove colleagues on a regular basis?
• Will they decide who the company's points of contact are?
• Do they need to change someone else's access, not just their own?

If the answer is no, member is the right role. A smaller circle of admins is easier to reason about, and it keeps the power to reshape the team in the hands of the people who use it.

You add people from My Organization in the account menu. The invite composer asks for a work email and a role, member by default. Cloud Sentry sends a signed invite link, and the recipient walks through accepting an invite on their side. Their acceptance shows up on your roster within a minute.

Two rules sit behind the form on purpose. The email domain has to match your company's verified domain, so a typo or an outside address cannot quietly join your roster. To add a second domain after an acquisition, you file a request and we wire it up. Invites also expire after 14 days; the pending list has a resend button when one goes stale.

Both rules are small, and both are security decisions wearing everyday clothes. Who can join your company's view of its own support history is exactly the kind of boundary that should be hard to cross by accident.

This is the setting that would have saved the Northwind manager a week. Your roster names a primary contact and a backup contact. The primary is who Cloud Sentry defaults to when we need a human decision: a routing question, a missing approval, an access change that needs a yes before we act. The backup is who we reach when the primary is unreachable.

You set both from the member dropdowns on the roster page, and you can change them any time. We use whoever is set at the moment a ticket needs a person. Most teams land somewhere like this:

• Primary contact: the technical lead who owns day-to-day decisions.
• Backup contact: the operations owner who can stand in without missing a beat.
• A short note to both that this is what the role means, so nobody is surprised by a call.

The point is not the titles. The point is that the question "who decides" has an answer before the moment you need it, so three people are not guessing while a new hire waits.

When you change a role or a contact, the change takes effect right away, and the affected person gets a courtesy email so nothing happens to them silently. Removing someone is just as direct: they lose access immediately, their open requests stay open and transfer to the primary contact unless you reassign first, and their request history stays attached to the company; it does not vanish with them. Re-invite a removed person later and their history re-attaches when they accept.

Every one of these moves, an invite, a role change, a removal, a contact swap, is written to the organization activity log with a name and a timestamp. That log is not paperwork for its own sake. It is the same answer to "who changed what, and when" that an auditor, an insurer, or a future version of you will eventually want.

Roles and contacts are a control, not a settings screen. Deciding who can reshape your team is the same muscle you use to decide who can reach your systems, and the cost of getting it vague is paid later, usually at the worst time.

Security and operations are not tool problems; they are problems of who is allowed to do what, and who answers when a person is needed. The new hire request did not stall because anyone lacked software. It stalled because the configuration that says "this person can act, and we call that person" had never been set on purpose. A small team that sets it well moves like a much larger one: the right people can act without asking, the wrong moves are hard to make by accident, and Cloud Sentry always knows who to call.

So the next time someone is out and a request needs a decision, the question is not who happens to be around. It is who you already decided should be holding the keys. Have you decided, or are you trusting that the right person will simply happen to be at their desk?