Olá

Entendo o seu processo, contudo o que você chama de reagendar, nada mais é do que uma nova agenda. 

Uma opção é informar ao seu cliente que o agendamento registrado foi inativado, ou seja, ser colocado numa fase de “Não comparecimento” e orientar a abertura de um novo agendamento, pois é isso que realmente está acontecendo.  Claro que haverá o inconveniente de ter que preencher todos os campos novamente, mas essa “consequência” é decorrente da não possibilidade do comparecimento.

Inclusive poderá criar um reporto e um KPI de todos os cards que ficaram na fase “Não comparecimento” para medir dias e horas de maior cancelamento, motivos (sugiro colocar opções: Trânsito, conflito de agenda, desistência e outros) para ajudar na avaliação.

Boa sorte

Exclusão de card via automação não é possível 

Bom dia pessoal,

Esse tipo de ação pode ser executada usando a automação de HTTP request, fazendo uma requisição para a própria API do Pipefy para fazer a exclusão.

Essa automação é um pouco mais técnica. Segue o artigo de ajuda sobre essa automação: https://help.pipefy.com/pt-BR/articles/8392669-como-criar-integracoes-com-requisicoes-http-com-automacoes

O campo request body ficaria algo assim:

{"query":"mutation {\n  deleteCard(input: {\n    id: \"CAMPO DINAMICO DO ID DO CARD A SER REMOVIDO\"\n  }) {\n    success\n  }\n}","variables":null}

Muito bom!

Olá,

Dá pra fazer isso, mas com automação externa, utilizando o Make.us

Eu faria da seguinte forma:

Criaria um webhook com filtro, para identificar quando um card fosse movinmentado da fase X para a fase Y (card retornando) no pipe A. 

Se isso acontecer, acionaria um gatilho, e eu deletaria o card o card conectado.

Existe várias formas de identificar o ID do card conectado, para inserir no módulo que irá deletar o card. A melhor, vai depender de como está construído seu pipe. 

Se precisar de mais detalhes desse caminho, me avise. 

{"query":"mutation {\n  deleteCard(input: {\n    id: \"CAMPO DINAMICO DO ID DO CARD A SER REMOVIDO\"\n  }) {\n    success\n  }\n}","variables":null}

Olá, Amanda!

Tenho o mesmo desafio relatado, porém, preciso excluir todos os cards que entrarem em determinada fase, até tentei usar essa linha de código no request body, porém, não obtive sucesso.

Eu posso criar um campo X, que toda vez que o card entrar nessa fase, o campo é preenchido automaticamente, e na automação de request HTTP, teria alguma forma de apontar que quando esse “campo x” for atualizado, fazer essa request que excluirá o card (e de que forma ficaria o request body nesse caso?)
Muito obrigado.

@fabio.maesta você pode criar o trigger do tipo “quando um campo for atualizado”, usando esse campo que você mencionou, ou até usar o trigger de quando o card entrar nessa fase (se for o caso de excluir o card sempre que ele entrar nessa fase).

E aí na action você seleciona a automação de HTTP request. O request body vai ser bem parecido sim.

A configuração da automação ficaria mais ou menos como o print abaixo: (anexei também o arquivo, caso a visualização não esteja boa)

O campo de authentication, no lugar no placeholder que incluí na imagem, você vai substituir pela sua chave de API, que você pode gerar aqui: https://app.pipefy.com/tokens

Oi!

Acho que você consegue fazer uma gambiarra para movimentar o card filho para uma fase Cancelado, por exemplo.

Vou te mostrar com os passos abaixo:

Para que a “gambiarra” funcione corretamente, o card filho precisa ser criado por dentro do card pai através da conexão de pipe.

No pipe B você vai criar uma fase chamada ‘Cancelado’ (minha sugestão) e depois vai criar um campo seleção de única opção com o nome ‘Reagendado’ e vai incluir as opções ‘Sim’ e ‘Não’ (minha sugestão). Depois cria uma condicional para esconder esse campo.
Após criar a condicional, você vai criar uma automação com o evento ‘Um campo for atualizado’, vai selecionar o campo ‘Reagendado’ e adicionar a condição ‘Reagendado’ é igual a ‘Sim’. A ação será ‘Mova um card’ e selecione a fase ‘Cancelado’.

No pipe A você vai criar uma automação com o evento ‘Um card entrar em uma fase’ e vai selecionar a fase ‘Reagendar’. Na ação você vai selecionar ‘Atualize um campo no card ou registro’, selecione a opção ‘Pipe ou database conectado’, e busque o campo de seleção única com o nome ‘Reagendado’ que você criou anteriormente.

Dessa forma, toda vez que você movimentar o card pai para a fase Reagendar, a automação vai atualizar o campo de nome ‘Reagendar’ no pipe filho e assim vai movimentar o card para a fase ‘Cancelado’.

Fiz isso em alguns pipes e funciona perfeitamente!

Boa sugestão!

{"query":"mutation {\n  deleteCard(input: {\n    id: \"CAMPO DINAMICO DO ID DO CARD A SER REMOVIDO\"\n  }) {\n    success\n  }\n}","variables":null}

OI, @amanda-dianni 

Tentei utilizar esse recurso, mas o card não é deletado

@marcosmelo pra mim funcionou… consegue enviar um print da configuração da sua automação?

Oi, @amanda-dianni 
Está dessa forma

 

@marcosmelo parece correto. No campo de Authentication, no valor, você deixou a palavra Bearer antes do valor do token?

@amanda-dianni 

Então eu tentei de várias formas, com a palavra bearer, sem a palavra, entre <>, sem <>, mas não deu certo 

No log de automações aparece isso

 

@amanda-dianni poderia dar uma forcinha aqui para o Marcos, por favor?

@marcosmelo desconfio que o token esteja incorreto.

Supondo que o meu token seja 1234, o valor do campo de authorization tem que ficar:

Bearer 1234

Foi, @amanda-dianni 

Muito obrigado!!!

Fala, povo, bom dia.

Como estão?

@Amanda Dianni , me ajude, também, por gentileza. 

Meu caso é muito parecido com o caso do Marcosmelo, porém, o meu confirma a automação e não deleta. O card continua lá.

@rvitoriano o endereço da api é /graphql e não /graphiql. Consegue tentar dessa forma?

kkkkkkkk… e voi’la.. obrigado..

PS: o que uma “mardita” letra errada não faz numa programação, né? kkkkkkkk

Haha acontece 

Do you have any alternate of this?