---
type: tutorial
title: Crie sua primeira equipe compartilhada
summary: Monte uma equipe compartilhada e convide três colegas, cada um com exatamente as permissões que seu papel precisa, acompanhando a BananaSeed enquanto ela forma um time.
---

Ao final deste tutorial, você terá criado uma equipe compartilhada e convidado três pessoas para ela, cada uma com um conjunto de permissões deliberadamente diferente: um líder de operações que conduz o time, um desenvolvedor que configura um produto e um gerente que só lê os números. Acompanhamos a **BananaSeed**, uma empresa cuja fundadora está montando um time.

Você precisa de um plano pago que inclua equipes compartilhadas (Troop ou Apex). No Solo ou Alpha você tem só a sua equipe **Pessoal**, que é só sua. Veja [faturamento](/docs/account-management/billing) para os planos, [o que é uma equipe](/docs/troops/overview) para o conceito, e [permissões e escopo](/docs/troops/permissions) para o modelo do qual os papéis abaixo se valem.

## A configuração

A fundadora da BananaSeed, Ana, superou sua equipe Pessoal. Ela tem dois produtos, cada um com sua própria chave de site, e três pessoas para trazer:

| Pessoa | Papel | Deve poder |
|---|---|---|
| **Dana** | DevOps | Conduzir o time: gerenciar membros e tokens de acesso. |
| **Raj** | Desenvolvedor | Personalizar a chave de site de um produto, e nada além disso. |
| **Mia** | Gerente | Ver os números em toda a equipe. Não mudar nada. |

Cada um mapeia para uma das quatro [permissões](/docs/troops/permissions): Dana precisa de **Gerenciar**, Raj precisa de **Editar** em uma chave, Mia precisa de **Ler**.

## 1. Crie a equipe e suas chaves

Na lista de equipes do painel, crie uma equipe chamada `BananaSeed`. Ela começa só com você, a dona, com todas as permissões. Crie nela as duas chaves de site, `shop.bananaseed.com` e `blog.bananaseed.com`, para que haja algo a que delimitar pessoas. (Veja [chaves de site](/docs/site-keys/overview).)

## 2. Convide Dana, a líder de DevOps (Gerenciar)

Na página **Membros** da equipe, convide Dana por e-mail. O convite é o próprio endereço de e-mail; quando Dana entrar com esse endereço, a associação dela fica ativa.

Conceda a ela só **Gerenciar**. Essa única permissão é a administração da equipe: ela pode adicionar, remover e mudar membros e [tokens de acesso](/docs/troops/tokens), e renomear ou excluir a equipe. Como Gerenciar vale para toda a equipe, o escopo dela não importa, então deixe em todas as chaves de site. Ela não precisa de Ler, Criar ou Editar para fazer seu trabalho; Gerenciar é a permissão de conduzir o time.

Agora Dana pode tirar o resto do onboarding das mãos de Ana: ela pode emitir um token de CI, adicionar a próxima contratação e ajustar permissões, tudo sem poder ser trancada para fora por escopo.

## 3. Convide Raj, o desenvolvedor de um produto (Editar, com escopo)

Convide Raj do mesmo jeito. Ele é dono da loja, não do blog, então:

- Conceda **Editar** (e **Ler** para que ele veja o que está editando). Editar permite que ele configure a chave: suas configurações, a rotação do segredo, a verificação hospedada e a [personalização de jogo e white-label](/docs/game-customization/overview) da chave.
- Defina o **escopo** dele como **chaves de site específicas** e escolha só `shop.bananaseed.com`.

Deixe **Gerenciar** desligado. Raj deve configurar seu produto, não conduzir o time. Com Editar delimitado a uma chave, é exatamente o que ele recebe: ele pode ajustar o desafio e o skin da loja, e não consegue tocar no blog, na lista de membros ou nos tokens.

Esta é a concessão de menor privilégio do dia a dia: uma permissão (Editar) limitada por um escopo (uma chave).

## 4. Convide Mia, a gerente que só lê (Ler)

Convide Mia e conceda só **Ler**, em todas as chaves de site. Ler permite que ela abra cada chave da equipe e olhe suas [estatísticas](/docs/troops/statistics), configuração e registros de auditoria, sem mudar nada disso. Ela recebe o panorama de toda a equipe de que precisa para relatórios, sem capacidade de editar uma configuração ou rotacionar um segredo por acidente.

## 5. Confirme cada concessão

Faça cada pessoa entrar e checar que a equipe se comporta como pretendido:

- **Dana** vê os controles de Membros e tokens e pode mudá-los, mas editar a própria configuração de uma chave de site não é a concessão dela.
- **Raj** consegue abrir e configurar `shop.bananaseed.com`, não vê `blog.bananaseed.com`, e não tem controles de Membros.
- **Mia** consegue abrir qualquer chave e ler suas estatísticas, mas todo controle de edição está ausente.

Esse é o ponto inteiro do modelo: três pessoas, três trabalhos, três alcances diferentes, nenhuma delas com mais do que precisa. No Apex, tudo o que cada uma faz é registrado sob a própria identidade no [registro de auditoria da equipe](/docs/audit-logs/troop-log).

## Para onde ir a seguir

- Adicione uma credencial de CI ou de serviço em vez de uma pessoa com um [token de acesso de equipe](/docs/troops/tokens), que carrega as mesmas permissões e escopo.
- Defina [substituições](/docs/troops/overrides) uma vez na equipe para que ambas as chaves herdem a marca.
- Acompanhe o uso nos dois produtos nas [estatísticas](/docs/troops/statistics) da equipe.

## Veja também

- [Permissões e escopo](/docs/troops/permissions): as quatro permissões por completo.
- [Assentos](/docs/troops/seats): como cada membro e token consome o pool de assentos do seu plano.
- [O que é uma equipe](/docs/troops/overview): o conceito e o que uma equipe detém.