Configuração de credenciais do cliente

Feedback General
1

Descreva o problema/erro/pergunta

Os clientes geralmente têm dificuldades em reconectar credenciais, APIs ou contas após a entrega do fluxo de trabalho?

Qual é a mensagem de erro (se houver)?

Por favor, compartilhe seu fluxo de trabalho

(Selecione os nós na sua tela e use os atalhos de teclado CMD+C/CTRL+C e CMD+V/CTRL+V para copiar e colar o fluxo de trabalho.)

Compartilhe a saída retornada pelo último nó

Informações sobre sua configuração n8n

  • Versão n8n:
  • Banco de dados (padrão: SQLite):
  • Configuração n8n EXECUTIONS_PROCESS (padrão: own, main):
  • Executando n8n via (Docker, npm, n8n cloud, app desktop):
  • Sistema operacional:
2

@ASHIM_DOLEY, depende. Seus clientes estão familiarizados com automação de fluxo de trabalho?

3

A maioria dos meus clientes-alvo são proprietários de negócios não-técnicos. Nesse caso, você acha que reconectar credenciais, APIs ou contas se torna um desafio comum de onboarding após a entrega do workflow?

4

Para clientes não-técnicos, a reconexão de credenciais é consistentemente o problema número 1 na entrega. Algumas coisas que reduzem o atrito:

  • Documente exatamente quais credenciais precisam ser reautorizadas e em qual ordem, antes de entregar. Um pequeno checklist numerado por integração funciona melhor do que um readme geral.
  • Para serviços Google, certifique-se de que a conta do cliente é usada durante o fluxo OAuth, não a sua - se você configurar com sua conta, eles precisarão reconectá-la de qualquer forma.
  • Para credenciais baseadas em chave de API, crie-as previamente no n8n com valores de placeholder e nomeie-as claramente (por exemplo, “[CLIENT] OpenAI Key - update before use”).
  • Para clientes muito não-técnicos, uma compartilhação de tela de 15 minutos para a entrega, onde eles autorizam cada credencial eles mesmos enquanto você os orienta, evita a maioria dos tickets de acompanhamento.
2 curtidas
How should client credentials be set up?
5

Yes, non-technical clients usually struggle with credentials after delivery unless the process is designed for it.

The best setup I have seen is to make credentials client-owned, but not client-unsupported. I would avoid asking for raw passwords or keeping personal access after handoff. Instead, use OAuth/service accounts where possible, document which account owns each credential, and keep a short reconnect runbook for every external system.

For handoff, I would include:

  1. Which credentials exist and what they connect to.
  2. Who owns each account on the client side.
  3. What happens when a token expires or an API scope changes.
  4. A test workflow or health check that proves the credential still works.
  5. A support boundary: what is included in maintenance versus a new change request.

The common mistake is treating credential setup as a one-time onboarding task. In practice it is a maintenance risk, especially with Google, CRMs, ad platforms, and anything with changing scopes. So I would make credential checks part of the ongoing support package.

1 curtida