Add or Remove a Team Member

This guide shows you how to give a new team member access to PushOps (SVIEW, Teleport, cloud accounts, Grafana, the Client VPN), and how to remove access when someone leaves — including exactly what to put in the request so it is done in one pass.

How access is built up

A person's access is made of separate layers. Knowing which layers they need is what makes a request complete:

Most people need only the first three. Ask for the others only when the person's job needs them.

Adding a new team member

What you can do yourself

1. Add the person to your identity provider group that your team already uses for SVIEW. They can sign in at your organisation's SVIEW URL straight away. If they were already signed in, they must sign out and back in, because group membership is read at sign-in.
2. Give them Service access, if your team restricts Services. Someone with permission to manage Services adds an entry with the person's email, exactly as they sign in, following Service Access Control.
3. Have them raise access requests for the namespaces, databases, Grafana or AWS Console roles they need. An approver in your organisation approves them.
4. Have them set up their Teleport sign-in once. Their Teleport account is not ready to use on first SVIEW sign-in, but they do not need CTO2B for it. In SVIEW they click their name in the top-right corner, choose Integrations, and click Connect on the Teleport card. SVIEW shows a link where they set their Teleport password; they then sign in to Teleport with their email address and that password. Until the password is set, the card shows In progress. See Set Up Teleport Sign-In With an Authenticator App or Security Key for the full steps.

If all of this works, you do not need to raise a request with CTO2B at all.

When to raise a request

Raise a request in your dedicated Slack channel when the person needs something your team cannot grant itself:

• your team signs in with a group that is not yet connected to SVIEW
• they need a role or approval rights your organisation does not have yet, such as a new AWS access role or the Approver role
• they need GCP project permissions, a Client VPN profile, or a database-level user you want CTO2B to create
• they are not part of your organisation's identity provider, such as a contractor or a third-party support engineer. SVIEW has no separate username-and-password sign-in: everyone signs in through a single sign-on option connected to your SVIEW (Google, GitLab, Okta or Microsoft Entra ID). CTO2B can connect a sign-in route the person already has, for example a GitLab group or their own company's Google domain. Once they can sign in to SVIEW, they set up Teleport the same way as anyone else, from Integrations.

What to include

Put all of this in the first message. Missing details are the main reason an access request takes several rounds.

• Who: full name and the email address they sign in with. For a group, the exact group name as your identity provider sends it.
• What: each system from the table above that they need.
• Where: the Environments or stages (for example development only, or development and production), and for databases the database name.
• Level: read-only or read-write, and for Grafana, Admin or Read-only. Ask for the least the job needs.
• How long: permanent, or an end date for temporary staff and auditors.
• Who approved it: the request must come from, or name, one of your organisation's contacts who can authorise access.

A request written like this is enough:

Please add Jane Doe ([email protected]), new backend developer:
- SVIEW: add to our existing developers group
- Teleport: read-write on the payments namespace in development, read-only in production
- Database: read-only on the orders database in production
- Grafana: Read-only
No VPN or AWS Console access needed. Approved by: <name, role>

Removing a leaver

Remove access on or before the person's last day. A former team member who can still sign in is a security risk.

1. Remove them from your identity provider, or from the group connected to SVIEW. This stops new sign-ins to SVIEW.
2. Remove any Service access entries that name their email directly, following Service Access Control.
3. Raise a removal request in your dedicated Slack channel, so CTO2B removes anything granted to them individually — Teleport roles, AWS access roles, GCP permissions and Client VPN profiles. Include their name, sign-in email, and the date access should end. Removal requests are handled with priority, ahead of new access.
4. Remove their database users, if your team created any inside a database.

Access requests already approved for them expire on their own, but do not rely on that — remove them explicitly.

Verify it worked

• New team member: they sign in to SVIEW, see the Services they need, and can raise an access request. Their User Profile shows their roles and active access.
• Leaver: they can no longer sign in to SVIEW. Their past requests stay visible under Access requests and in Audit Logs.

Common issues

• Added to the group but still no access. Ask the person to sign out and back in. If that does not help, check the group is the one connected to SVIEW, and raise a request with the group name and their email.
• Connected to a database but permission denied. Teleport lets them reach the database; the database user and grants decide what they can do inside it. Check the database user exists.

Related articles

• Set Up Your PushOps Access — signing in to SVIEW for the first time
• Access Requests — raising and approving time-limited access
• Service Access Control — Read, Write and Admin on each Service
• User Profile — checking a person's roles and active access
• Temporary AWS Console Access Through Teleport
• Client VPN
• Namespace Access
• Set Up Teleport Sign-In With an Authenticator App or Security Key