# CRM — Resolve Context

Sub-workflow: de uma caixa de vendedor e um e-mail de cliente, devolve a Membership, a pessoa e o Deal aberto no CRM.

| Platform | Workflow ID | Status | Version | Last saved | Nodes | Systems |
| --- | --- | --- | --- | --- | --- | --- |
| n8n | WkbRsPadLZfEgxTu | Inactive | 044a2d8c-ed1f-463f-9eae-3a8498928609 | 2026-11-06T21:25:38.009Z | 11 | CRM, Tooling and Access |

O CRM — Resolve Context responde uma pergunta para outros workflows: dada a caixa de um vendedor e o endereço de e-mail de um cliente, quem são eles no CRM? Ele devolve a Membership e a empresa do vendedor, o cliente como pessoa do CRM com a empresa dela, e o Deal aberto do cliente, preferindo o que pertence a esse vendedor. Ele só lê. Nunca cria uma pessoa nem um Deal.

É um sub-workflow: não tem gatilho próprio e roda quando outro workflow o chama. O [Email Capture](/pt-br/automations/email-capture) chama ele uma vez por e-mail. O Cal.com Booking Intake ainda faz as mesmas buscas por conta própria; passar para este sub-workflow é um work item pendente.

O maintainer do CRM cuida das Memberships, People e Deals que ele lê; o do Tooling and Access cuida da Tool Account e do Identity Binding dela.

## Fluxo

Gerado da versão do n8n do quadro acima: cada caixa é um nó e cada seta é uma ligação no n8n. Pílulas rosa são gatilhos, hexágonos amarelos são nós If e Switch com as saídas nas setas, cilindros azuis leem (Airtable, Data Table, HTTP GET), cilindros verdes gravam, caixas roxas chamam outro workflow e setas tracejadas são saídas de erro.

```mermaid
flowchart TD
  subgraph g0["Pedido"]
    n1(["Context Request"]):::trigger
    n0["Build Lookups"]:::logic
  end
  subgraph g1["Vendedor"]
    n6[("Find Tool Account<br/><small>GET Tooling Tool Account</small>")]:::read
    n9["Resolve Seller"]:::logic
    n3[("Find Membership (CRM)<br/><small>GET CRM Membership</small>")]:::read
    n4[("Find Membership by Email<br/><small>GET CRM Membership</small>")]:::read
  end
  subgraph g2["Contraparte e Deal aberto"]
    n5[("Find Person (CRM)<br/><small>GET CRM People</small>")]:::read
    n8["Resolve Person"]:::logic
    n2[("Find Deals<br/><small>GET CRM Deal</small>")]:::read
    n7["Resolve Context"]:::logic
  end
  n1 --> n0
  n0 --> n6
  n6 --> n9
  n9 --> n3
  n3 --> n4
  n4 --> n5
  n5 --> n8
  n8 --> n2
  n2 --> n7
  classDef trigger fill:#fde7f3,stroke:#d6409f,color:#111
  classDef decision fill:#fff7e0,stroke:#c99a00,color:#111
  classDef read fill:#e8f1ff,stroke:#3b82f6,color:#111
  classDef write fill:#e7f8ee,stroke:#16a34a,color:#111
  classDef subflow fill:#f3e8ff,stroke:#9333ea,color:#111
  classDef wait fill:#f1f1f1,stroke:#888,color:#111
  classDef logic fill:#ffffff,stroke:#999,color:#111
```

## Sistemas que ele toca

| Sistema | Tabela | Lê | Grava |
| --- | --- | --- | --- |
| Tooling and Access | Tool Account | Find Tool Account | Nada |
| CRM | Membership (mirror) | Find Membership (CRM), Find Membership by Email | Nada |
| CRM | People (mirror) | Find Person (CRM) | Nada |
| CRM | Deal | Find Deals | Nada |

Toda chamada ao Airtable é um nó HTTP Request com uma credencial de token do Airtable. As leituras filtram pelo nome do campo: `{Login Alias}` e `{Tool}` em Tool Account, `{Membership #}` e `{Company Email}` no mirror Membership, `{Email}` no mirror People e ids de registro em Deal. Renomear um desses campos quebra a busca sem erro: o nó não devolve registro e o fluxo segue como se nada tivesse sido encontrado.

## Entrada e saída

O Context Request recebe três valores de quem chama:

| Entrada | Significado |
| --- | --- |
| `sellerEmail` | A caixa interna que enviou ou recebeu o e-mail |
| `counterpartyEmail` | O endereço da pessoa externa |
| `counterpartyName` | O nome de exibição do e-mail, usado só nas notas |

O Resolve Context devolve um item:

| Saída | Valor |
| --- | --- |
| `toolAccountId` | A Tool Account do Tooling do vendedor, quando encontrada |
| `membershipId`, `membershipNumber` | O registro do mirror Membership do CRM do vendedor |
| `accountableCompanyId` | A Business Unit dessa Membership |
| `personId`, `personName`, `personCompanyId` | O registro do mirror People do CRM da contraparte e a primeira empresa das memberships dela |
| `dealId`, `dealStage` | O Deal aberto escolhido, quando há |
| `openDealCount` | Quantos Deals abertos a pessoa tem |
| `notes` | Avisos e notas, uma linha cada, para quem chama guardar |

## Vendedor

O Build Lookups põe os dois endereços em minúsculas e monta as fórmulas. O Find Tool Account procura no Tooling a Tool Account cujo Login Alias é o endereço do vendedor e cujo Tool contém Google Workspace. O Resolve Seller lê o Bound Membership ID dela. O Find Membership (CRM) procura o registro do mirror Membership cujo Membership # começa com esse número seguido de " - ". O Find Membership by Email procura o registro do mirror Membership cujo Company Email é o endereço do vendedor.

O Resolve Context fica com a Membership achada pelo número, depois a achada pelo e-mail. A Business Unit dela vira a empresa responsável. As notas dizem qual caminho foi usado e o que falta: sem Tool Account e sem Company Email; achada só pelo e-mail (adicione um Identity Binding); Tool Account sem binding.

## Contraparte e Deal aberto

O Find Person (CRM) procura o e-mail da contraparte no mirror People do CRM. O Resolve Person lê as empresas da pessoa e os ids em Deals (Counterparty), e monta a busca dos Deals. O Find Deals lê esses Deals.

O Resolve Context fica com os Deals cujo Deal Status é Open. Quando o vendedor é conhecido como Person do CRM (o Member da Membership encontrada), ele pega o primeiro Deal aberto cujo Accountable (Person)* o contém, e nenhum nos outros casos. Quando o vendedor é desconhecido, pega o primeiro Deal aberto. As notas registram pessoa fora do mirror, ou pessoa sem Deal aberto.

## Nós

O workflow tem 11 nós: 10 que executam e uma nota adesiva.

| Nó | Tipo | O que faz |
| --- | --- | --- |
| Context Request | executeWorkflowTrigger | Recebe sellerEmail, counterpartyEmail e counterpartyName de quem chama |
| Build Lookups | code | Põe os endereços em minúsculas e monta as três fórmulas |
| Find Tool Account | httpRequest | Tool Account do Tooling por Login Alias e Tool |
| Resolve Seller | code | Lê o Bound Membership ID e monta a busca da Membership por número |
| Find Membership (CRM) | httpRequest | Mirror Membership do CRM pelo número da membership |
| Find Membership by Email | httpRequest | Mirror Membership do CRM pelo Company Email |
| Find Person (CRM) | httpRequest | Mirror People do CRM pelo e-mail da contraparte |
| Resolve Person | code | Lê as empresas da pessoa e monta a busca dos Deals |
| Find Deals | httpRequest | Os Deals da pessoa |
| Resolve Context | code | Escolhe a Membership e o Deal aberto; devolve o contexto e as notas |
| Sticky Note | stickyNote | Nota de configuração no canvas; não executa |

## Ligações

| De | Saída | Para |
| --- | --- | --- |
| Context Request | 0 | Build Lookups |
| Build Lookups | 0 | Find Tool Account |
| Find Tool Account | 0 | Resolve Seller |
| Resolve Seller | 0 | Find Membership (CRM) |
| Find Membership (CRM) | 0 | Find Membership by Email |
| Find Membership by Email | 0 | Find Person (CRM) |
| Find Person (CRM) | 0 | Resolve Person |
| Resolve Person | 0 | Find Deals |
| Find Deals | 0 | Resolve Context |

## Configurações e tratamento de erro

| Configuração | Valor |
| --- | --- |
| Status | Inativo; um sub-workflow roda quando é chamado mesmo inativo |
| Ordem de execução | v1 |
| Workflow de erro | Nenhum |
| Retry on fail | Em todos os nós HTTP Request, 3 tentativas |
| On error | Para o workflow (padrão) em todos os nós; quem chama recebe o erro |
| Caller policy | Workflows do mesmo dono |
| Retenção dos dados de execução | Padrão da instância; este workflow não define |

## Antes de ativar

| Passo | Onde | Estado na última revisão |
| --- | --- | --- |
| Toda caixa de vendedor tem uma Tool Account (Google Workspace, Login Alias = e-mail) com Identity Binding válido | Tooling and Access | Pendente; sem isso o vendedor resolve só pelo Company Email, ou não resolve |
| O mirror Membership do CRM tem o Company Email | CRM | Presente |

## Lacunas conhecidas

| Lacuna | Efeito |
| --- | --- |
| Os nós Find leem uma página (até 100 registros) | Uma pessoa com mais de 100 Deals pode cair no errado |
| A primeira empresa das memberships da pessoa é a escolhida | Uma pessoa com memberships em várias empresas fica com a primeira em `personCompanyId` |
| Sem Membership do vendedor, o primeiro Deal aberto é o escolhido | A thread pode cair no Deal de outro vendedor |
| A escolha do Deal ignora o stage | Um Deal num stage avançado continua sendo o aberto |

## Manter esta página em dia

O quadro no topo mostra a versão do n8n que esta página descreve. Abra o workflow no n8n: quando o último salvamento dele é mais novo que a data do quadro, esta página está desatualizada até a próxima revisão. Todos os nós e todas as ligações dessa versão estão em [Nós](#nodes) e [Ligações](#connections).