Provisioning users and defining teams

Critical to achieving service ownership and catalog completeness is making sure developers have access to their team’s service data and visibility into who to contact for services they don’t own—especially as new teammates are added or change teams. OpsLevel makes it easy for admins to provision or de-provision users, categorize them within their teams, and assign ownership to the right individuals to ensure that they have all the context they need. Here’s how:

Roles in OpsLevel

Anyone invited into OpsLevel can be set up as a user or an admin. Admins are typically your DevOps, Infra, or Platform engineers responsible for configuring and maintaining developer tools. Admins have full access to a domain and can change settings across checks, campaigns, filters, accounts, and more. Users are typically your product developers—the ones that OpsLevel supports day in and day out. Users are restricted in the actions they can perform and the information they can see. 

For instance, Admins have full access to manage Actions in the Self-Service Hub. This means they can build new Actions from scratch or configure them from the library of templated Actions provided. Users, on the other hand, will only have access to Actions that are set up for their teams when they navigate to the Self-Service Hub.

Provisioning users

Accurate user management is a critical piece of service ownership, which is why OpsLevel makes it easy to add, remove, and move around users in your domain. 

Upon first login, each new user is prompted to add themselves to their team(s). If they haven’t done so within 10 days of being invited, they’ll get pinged from our Slack integration. We also support user provisioning and team assignments via the GraphQL API.

With people coming and going as the org evolves, user management can become tedious, so OpsLevel also offers SCIM native support with Okta and Azure Active Directory. Whenever anyone is activated/deactivated in IdP, they will lose or gain access to OpsLevel automatically, giving you peace of mind around security.

Ownership visibility across teams

Once provisioned, users can join their specific teams to get access to the correct product area. In this way, OpsLevel gives you a functional org chart that updates every time someone moves to a different product so developers don’t have to waste time trying to figure out who actually owns a service.

How Teams work in OpsLevel

Teams promote and simplify service ownership by showing which teams own what services, who the team lead is, and who can be contacted for questions. OpsLevel’s philosophy is that team ownership of services ensures there’s always back up support and someone from the owning team can take responsibility.

In the event of an outage, for example, you could use the Service Catalog View or Dependency Map to see who owns the service then navigate to the Team page, and contact the team lead or on-call. Or you could sync team membership files from OpsLevel to all your repos to ensure that new pull requests get approval from a member of the owning team.

How team hierarchies work in OpsLevel

Teams can also contain sub-teams, arranging individual teams into any series of nested groups to represent your functional org structure in OpsLevel. For example, you could create an e-commerce parent team composed of the various teams building and maintaining your checkout service.

What else you need to know about teams

• All teams (including these broader parent teams) can own services. This gives you the flexibility to assign ownership at a higher level if several individual teams under a single purview own a given service. 
• The team hierarchy also offers a reporting advantage—just filter the maturity report by the parent team to see how its sub-teams and services are performing.
• Teams can have multiple managers to support a more accurate reflection of your organizational structure.

Groups also offer a reporting advantage—just filter the maturity report by group to see how teams and services are performing across that group.

Utilizing teams to their full potential helps you move away from static, outdated org charts that make it difficult to know who’s responsible for what, and who to contact for which services. This empowers teams across your product org to take responsibility for what’s theirs, and simplifies the search process when a problem arises so you can resolve it faster.