Limites e Pacotes de Expansão

Como medimos o uso do sistema e seus pacotes de expansão.

Disparos de Automação

Um disparo de automação é a métrica de uso automações/integrações sem código. Um disparo de automação será contabilizado para cada vez que uma ação de automação for executada. Se uma automação disparar 5 ações, serão contabilizados 5 disparos de automação.

Automação e integração sem código:

  • Quando um novo registro for criado, envie uma mensagem no Slack. (1 disparo de automação)
  • Quando um registro for atualizado para o status "Concluído" na tabela A, envie um e-mail e crie um novo registro na tabela B. (2 disparos de automação).

Integração e Automação Zapier

  • Ações e gatilhos de Zapier baseados no Jestor contarão como 1 disparo de automação. Então se você possui um zap que é definido como:

Quando um registro é criado no Jestor -> Atualizar um registro no Jestor

Isso contará como 2 disparos de automação.

Automações gratuitas sem código

  • Algumas automações nativas sem código são gratuitas. Elas não serão considerados em seu limite de taxa de execuções por mês, mas podem ter um limite máximo. Quando não especificado um limite, serão limitados a 5.000 execuções/mês para cada automação.
  • As automações gratuitas serão marcadas como "Free" com um rótulo verde.
240

Você pode conferir o total do uso em "Free runs" dentro de Configurações -> Uso:

Webhooks

  • Existem dois tipos de webhooks dentro do Jestor: webhooks de objeto e de função. Webhooks de função são webhooks que, quando ativados, executam uma função Low-code. Assim, eles seguem regras de Low-code, que estão descritas mais abaixo nesta seção.

Para um exemplo mais detalhado, consulte Automação e integração Low-code abaixo.

Combinando automações no-code e low-code

  • É possível combinar automações sem código com funções de Low-code. Ou seja: invocar uma função low-code no meio de sua automação sem código. Nesse cenário, as ações sem código contarão como 1 disparo de automação cada, e a função de Low-code seguirá as regras de Low-code.

Por exemplo, se você tiver uma sequência de automação semelhante a:

  • Quando um novo registro for criado, envie uma mensagem do Slack e execute uma função Low-code.

Você tem:

  • Quando um novo registro é criado (1 disparo de automação).
  • Envie uma mensagem Slack (1 disparo de automação).
  • Execute uma função Low-code (uso low-code).

Então, neste exemplo você terá um total de 2 disparos de automação mais uma medição de uso low-code toda vez que essa sequência for ativada.

📘

Limites de disparos de automação

É contabilizado mensalmente, não cumulativo.

Cada plano tem seu próprio limite de taxa. Você pode conferir aqui.

Os pacotes complementares estão disponíveis? Sim.

Há algumas coisas a ter em mente ao lidar com automações:

🚧

Aviso

  1. Uma sequência de automação pode ativar outras sequências de automação. Por exemplo, se você configurar uma automação que atualiza um registro e, em seguida, configurar uma automação que seja executada quando um registro for automatizado, a segunda sequência será ativada sempre que a primeira for executada. Isso pode criar uma grande árvore de automações que consome limites e pode até cair em loop infinito (consulte Loop infinito e recursão circular abaixo).

  2. Como o simples ato de executar automações consome poder de processamento, as automações contarão para o seu limite mesmo que falhem, independentemente de falharem por erros lógicos, instabilidades ou mesmo se forem bloqueadas por regras de recursão ou timeout.

Low-code Usage

Uso de Low-code é a métrica de uso para automações/integraçõs low-code. O Uso é medido em GBs (Gigabyte x segundo) e é calculado multiplicando o tempo de execução da automação/integração pelo total de memória alocado para a execução.

Por exemplo, se você disparar uma automação low-code que:

  • Teve uma alocação de memória de 128MB, ou seja: 0.125GB dada a conversão efetiva.
  • Executa por 600ms, ou seja: 0.6s.

Você terá um uso total de 0.125GB x 0.6s = 0.075GBs.

Como automações low-code podem variar vastamente de escopo, esta forma de medir uso permite uma construção mais flexível de processos internos. Automações de pequeno escopo que executam por um baixo período de tempo consomem menos do que automações de largo escopo que executam por um período maior de tempo, permitindo o uso mais abrangente de low-code sem penalizar processos simples.

Cadeias de Automação

Dependendo de como você define seus gatilhos e ações, as sequências de automação podem desencadear outras sequências de automação e executar em paralelo em vários níveis. Por exemplo, se você tiver essas duas sequências de automação:

  • Quando um novo registro for criado em Vendas, crie um registro em Contratos.
  • Quando um novo registro for criado em Contratos, envie uma mensagem no Slack.

Sempre que o primeiro for executado, ele ativará o segundo. Isso significa que a primeira sequência de automação é o primeiro nível da automação e a segunda é o segundo nível. Se a segunda automação desencadeasse outra sequência de automação, seria o terceiro nível e assim por diante.

Isso é chamado de cadeia de automação* e eles podem executar apenas sete (7) níveis de profundidade**. Cadeias de automação que excedam esta limitação podem ser bloqueadas.

Chamadas de API

Chamadas de API e Webhooks serão medidos separadamente das execuções de automação. Ambos contarão como "chamadas de API".

📘

Limite de chamads de API

Máximo de 10 chamadas de API por segundo, 26.000.000 chamadas de API por mês, não cumulativo.

Os pacotes complementares estão disponíveis? Apenas para o plano Enterprise.

Os limites acima são limites, não garantias de desempenho:

🚧

Limitações induzidas pelo estresse

Às vezes, as chamadas de API podem desencadear automações ou até mesmo demorar um pouco para terminar porque dependem de processos externos ou gerenciam grandes quantidades de dados. Nesses casos, pode não ser possível fazer 10 chamadas de API em 1 segundo.

O que é uma chamada de API (interfaces de programação de aplicativos)?
As APIs são uma maneira de um programa se comunicar com outro estabelecendo pontos de extremidade onde os programas podem fazer solicitações (chamadas) para buscar ou enviar dados. As APIs possibilitam integrações entre diferentes ferramentas.

Sempre que um sistema (A) se comunica com outro (B), é uma "chamada de API" ou "solicitação de API". Em cada solicitação (A para B ou B para A), você pode enviar um (ou vários) parâmetros e um (ou vários) registros ao mesmo tempo.

Em outras palavras, toda vez que uma solicitação for enviada para um terminal Jestor, ela contará como 1 chamada de API.

Exemplo
A execução do trecho de código abaixo faria uma chamada de API para https://documentation.api.jestor.com/object/list para obter registros/cartões da tabela "sample_table". Portanto, executá-lo uma vez contaria como 1 chamada de API.

curl --request POST \
     --url https://documentation.api.jestor.com/object/list \
     --header 'Authorization: Bearer MjE5NzEzYWM0OWU2N2M5cd014f3bd4MTYxNjYwNDg2NWMzM2Nl' \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --data '
{
     "object_type": "sample_table",
     "sort": "number_field desc",
     "page": 1,
     "size": "100"
}
'

É importante observar que o endpoint /object/list tem um limite de resposta de 200 registros, portanto, se você tiver 1.000 registros em uma tabela e chamar o endpoint 5 vezes para buscá-los, isso contará como 5 chamadas de API.

Automação e integração do SDK

  • Jestor SDKs são essencialmente atalhos para endpoints de API, para que você possa obter os mesmos resultados com menos código. Isso significa que os métodos do SDK são essencialmente chamadas de API para pontos de extremidade específicos e o uso de um método equivale a 1 chamada de API.

Webhooks

  • Existem dois tipos de webhooks dentro do Jestor: webhooks de objeto e de função. Webhooks de objeto são webhooks que, quando ativados, criam um registro diretamente em uma tabela. Como tal, eles são essencialmente terminais públicos que você pode ativar ou desativar à vontade. Isso significa que ativar um webhook de objeto uma vez equivale a fazer 1 chamada de API.

Tamanho da Tabela

Registros por Tabela

Cada linha em uma tabela é um registro. Existem vários tipos de visualizações de dados no Jestor que são baseados em tabelas. Dessa forma, você também pode pensar em cada cartão em um kanban como um registro ou cada linha em uma lista.

É importante observar que as visualizações não contam como registros extras. Se você tiver uma tabela Vendas com 25 registros e ativar uma exibição kanban para ela, ainda terá 25 registros no total para essa tabela. O que conta é o número total de registros na tabela em que as exibições são baseadas.

📘

Limite de registros por tabela

O número de linhas da maior tabela será aquele que define seu uso atual. É um limite por tabela e é cumulativo. Se você adicionar mais registros em meses diferentes na mesma tabela, todos serão considerados.

Cada plano tem seu próprio limite de tabela. Você pode conferir aqui.

Os pacotes complementares estão disponíveis? Sim.

Tamanho Estrutural

Como em qualquer outro banco de dados relacional, nossas tabelas têm limitações de tamanho estrutural. Pode atingir um limite estrutural de bytes de informação dependendo do número de colunas, tipo de colunas e dados em uma linha. Isso não significa que você não pode ter arquivos que excedam esse limite, porque os arquivos são arquivados em diferentes estruturas.

Atingir essa limitação é comum quando você tem muitas colunas em uma única tabela. A solução para esse problema é redesenhar seu processo ou estrutura de dados para usar mais de uma tabela. Todos os campos da tabela conectados podem ser úteis para espalhar os dados em diferentes tabelas. Assim, criando uma estrutura de dados muito melhor e uma ferramenta interna de melhor desempenho.

Campos de cálculo (fórmula, lookup, etc) e campos de conexão têm um limite de 20 por tabela. O ideal para cálculos das tabelas é criar indicadores, gráficos, e outros instrumentos de cálculo via Páginas de App.

📘

Limite estrutural por tabela

Você pode ter até 60.000 bytes de dados estruturais em uma linha da tabela.

Os pacotes complementares estão disponíveis? Não.

Loop Infinito e Recursão Circular

Às vezes, sequências de automação em cadeias de automação podem acabar ativando sequências ativadas anteriormente. Isso significa que a automação será executada indefinidamente, pois continuará voltando às etapas anteriores.

Chamamos esses tipos de cenários de loops infinitos, ou recursão circular, porque se não forem interrompidos, eles serão executados para sempre.

Um exemplo clássico seria algo como:

  • Quando um novo registro for criado em Vendas, crie um registro em Contratos.
  • Quando um novo registro for criado em Contratos, crie um registro em Vendas.

Assim, sempre que um registro é criado em Vendas ou Contratos, uma automação criará um registro na outra tabela e ativará uma automação que cria um registro de volta na tabela original. Por causa desse erro lógico, essa sequência nunca terminará sozinha.

Loops infinitos e recursão circular podem prejudicar a experiência do usuário, pois tendem a esgotar os recursos e alterar os dados indefinidamente. Dependendo da natureza da recursão, o Jestor pode bloquear automaticamente a continuação dessas sequências de automação e desabilitar as automações que as originaram.

🚧

A recursividade conta para seus limites de taxa

Independentemente de a sequência de automação estar bloqueada ou não, cada execução de automação, chamada de API ou qualquer outro limite de taxa afetado por ela ainda contará para o uso de sua conta. Isso será válido mesmo se a automação for revertida ou causar erros e o resultado desejado da automação não for alcançado.

Timeout de Chamadas

Sempre que houver uma chamada ou query na sua conta Jestor, existe um limite máximo de tempo que essa chamada pode ser executada antes de ser invalidada. O limite para chamadas é um minuto. Isso significa que chamadas que atingirem esse limite ativarão o timeout e serão descartadas, e não serão executadas inteiramente.

Tenha em mente que este limite se estende a todas as chamadas, como buscar dados para mostrar informações em um kanban ou fazer a atualização de um registro.

A maior parte das chamadas deve ser executada em milissegundos e, por isso, esta limitação não deverá impactar sua conta em condições normais. Timouts geralmente ocorrem como uma medida de segurança em contas que estejam sob uso anormal, como por exemplo sob o estresse de automações presas em loops lógicos.

Recursos Premium

Os recursos premium são funcionalidades específicas que estão disponíveis apenas para alguns planos. Você pode identificar recursos premium por meio de indicadores como títulos de identificação, descrições, banners "premium" na parte inferior dos ícones de um recurso ou qualquer outro tipo de símbolo gráfico que possa indicar que o recurso é Premium.

A imagem abaixo é um exemplo de como pode ser um banner "premium":

Recursos Complementares

Recursos complementares são recursos do sistema que devem ser adquiridos além de um plano.

Uso de Bots

Bots são programas de computador que simulam o comportamento humano.

❗️

É proibido. Adicionar bots no Jestor é contra os termos de uso

Você não pode tentar simular o uso humano usando bots. Se um bot for detectado, o usuário será excluído e a conta poderá ser bloqueada.

Importações de Dados do Conector

Você pode importar planilhas para o Jestor, criando automaticamente novos registros e campos.

📘

Limite de Taxa de Número de Registros Importados

Cada importação tem um limite de 7500 células de uma planilha.

Os pacotes complementares estão disponíveis? Não.

Armazenamento

Existem dois tipos de limites de armazenamento no Jestor: arquivos únicos e armazenamento de tabelas.

  • *Single files: o tamanho máximo de um único arquivo que você carrega no Jestor, por exemplo, imagens ou PDFs. Para qualquer plano, o tamanho máximo permitido é de 100 MB.
  • *Armazenamento de tabela: o tamanho combinado de todos os arquivos carregados em uma única tabela ou página. Por exemplo, se você tiver uma tabela de propostas com 5 registros e cada registro tiver um arquivo PDF de 5 MB, o armazenamento total usado para essa tabela será de 25 MB. por exemplo, imagens ou PDFs. Cada plano tem seu próprio limite de armazenamento de tabelas. Você pode conferir aqui

Atingindo Limites

Se você atingir qualquer um dos limites, poderá ser impedido de realizar ações relacionadas a esse limite.

Por exemplo:

  • Se você tiver um limite de 5.000 execuções de automação e executar 5.000 automações em um mês, as automações não serão acionadas novamente até o mês seguinte ou você expandirá seus limites por meio de complementos ou alteração de planos.
  • Se você tiver um limite de 25.000 registros por tabela e atingir um total de 25.000 em uma tabela, não poderá criar novos registros até excluir registros pré-existentes ou expandir seus limites por meio de complementos ou alteração de planos .

🚧

Planeje com antecedência e não perca dados!

Se você atingir os limites de taxa da sua conta, poderá acabar perdendo dados ou interrompendo processos devido a recursos ou funcionalidades bloqueadas. Esses não serão executados retroativamente. Desbloquear afetará apenas ações futuras.

É sua responsabilidade ter os complementos, planos ou comportamento de uso geral corretos que atendam às suas necessidades operacionais.