FAQ sobre a ferramenta de migração

Ferramenta de migração para regras de criação automática de registos e contratos de nível de serviço (SLAs)

Quem pode aceder ou executar a ferramenta de migração?

Administradores e utilizadores com funções de gestor do CSR podem executar a ferramenta de migração.

As regras migradas são automaticamente ativadas após a migração?

Não Deve ativar manualmente as regras migradas quando a migração estiver completa.

Posso continuar a utilizar as minhas regras legadas após o prazo de preterimento?

Sim. As regras legadas ativas continuam em execução após o prazo de descontinuação, até serem desativadas. No entanto, a experiência de edição e a capacidade de suporte param após o preterimento.

Posso ativar uma regra que tenha um estado de migração "incompleto"?

Não Uma regra migrada é ativada apenas quando alterna o comutador Marcar como concluído para Sim depois de rever uma regra incompleta e corrigir quaisquer problemas presentes. É quando a regra é considerada migrada com êxito.

A regra legada é desativada após a migração?

• Para criação automática de registos, sim. Quando ativar uma regra de criação automática de registos migrada na Interface Unificada, a regra legada correspondente é desativada.
• Para SLAs, não. Quando ativar uma regra SLA migrada na Interface Unificada, a regra legada correspondente permanece ativa porque as duas regras podem coexistir.

O que significa um estado "incompleto"?

• Na secção Resumo: O processo de migração global não conseguiu concluir com sucesso a migração de todas as regras selecionadas.
• Ao lado de uma regra:: A regra falhou ou a regra não pôde ser totalmente migrada (ou seja, um ou mais itens ou condições não puderam ser migrados).

Onde posso encontrar uma lista de regras parcialmente migradas que são rastreadas na ferramenta de migração?

As regras migradas parcialmente ou identificadas como migradas incompletamente não são consideradas totalmente migradas. Portanto, são monitorizadas sob Pendente na secção Resumo. Apenas as regras que completaram a migração com sucesso são contadas em Migradas.

A ferramenta de migração suporta formulários ou campos personalizados?

• Para criação automática de registos, sim. A ferramenta de migração suporta entidades, campos, atributos e configurações.
• Para SLAs, não. A ferramenta de migração não suporta totalmente entidades, campos, atributos e configurações personalizados. Para concluir a migração, os utilizadores devem modificar quaisquer fluxos de personalização, workflows, plug-ins ou outros códigos personalizados existentes nas entidades, campos, atributos e configurações personalizados.

Preciso de uma licença separada do Power Automate antes de executar a migração?

Não Para obter mais informações sobre as diretrizes de licenciamento, vá a O que são os direitos de utilização do Microsoft Power Apps e do Power Automate para aplicações Dynamics 365?

Algumas das minhas regras estão incompletas ou parcialmente migradas. O que devo fazer?

Pode utilizar os detalhes do problema para corrigir a regra no cliente Web e, em seguida, voltar a executar a migração ou corrigir a regra migrada diretamente na Interface Unificada.

Posso repetir a ferramenta de migração para uma regra específica migratória?

Sim, pode voltar a executar a ferramenta de migração para uma regra migrada específica baseada nos seguintes critérios:

• Para regras incompletas ou regras de migração falhadas: selecione a mesma regra quando voltar a executar a ferramenta de migração. A ferramenta substitui automaticamente a regra existente falhada ou incompleta pela regra recém-migrada.
• Para regras migradas com sucesso: elimine a regra migrada na Interface Unificada antes de volta a executar a ferramenta de migração.

Após a conclusão da migração, o que acontece aos registos de SLA existentes associados aos SLAs legados?

• Se o SLA legado for desativado após a migração: O temporizador continuará a funcionar até ao estado terminal desses registos de SLA. No entanto, a funcionalidade Resolver e Pausa não funcionará.
• Se o SLA legado ainda estiver no estado Ativo: Os registos de SLA existentes associados a SLAs legados continuarão a funcionar conforme esperado.
• Se quiser usar SLAs criados nas aplicações Interface Unificada em registos existentes: Terá de atualizar manualmente o campo SLA para Interface Unificada SLA ou escrever o plugin para atualizar os registos. Por exemplo, a lógica do plugin pode ser Fluxo moderno ou Fluxo de trabalho.

Para obter informações sobre regras ou fluxos migrados na criação moderna de registos automáticos, aceda a FAQ sobre a criação automática moderna de registos.

Problemas conhecidos de conversão de condição

Esta secção descreve os principais cenários em que regras ou itens não concluem a migração com êxito.

Se os meus itens de regras ou condições tiverem entidades relacionadas dentro de uma cláusula de grupo aninhada (e/ou), serão migradas para a Interface Unificada?

Não Atualmente, suportamos apenas um nível da hierarquia da entidade relacionada. Tais itens de regra ou condições só podem ser migrados com sucesso se remover qualquer entidade relacionada na cláusula de grupo antes de migrar. Se não tomar nenhuma ação, a regra falhará durante o passo de Verificação de pré-migração. Se optar por continuar com a migração, a regra terá uma condição vazia para o item relacionado.

Exemplo: entidades relacionadas numa cláusula de grupo aninhada

Vista de cliente Web de pré-migração

Legenda:

a. O título do item.

Vista da Interface Unificada pós-migração

Legenda:

2a. "_FailedMigration" foi anexado ao título do item migrado.

2b. O mesmo marcador de posição padrão Criado em igual 2200-01-01 é adicionado à condição.

Por que razão os meus itens de regra ou condições com um campo DateType que utiliza um operador Not-On falham durante a verificação de pré-migração e a migração real?

O operador Not-On para o tipo de dados Data não é compatível com Interface Unificada. Portanto, não há suporte como parte da migração. Para corrigir este problema, pode alterar os itens ou condições antigas de {not-on selecteddate} para {selecteddate inferior a e selecteddate superior a} no cliente Web antes de voltar a executar a ferramenta de migração para a regra correspondente.

Exemplo: campo DateType que usa um operador Not-On

Vista de cliente Web de pré-migração

Legenda:

a. O título do item.

Vista da Interface Unificada pós-migração

Legenda:

2a. "_FailedMigration" foi anexado ao título do item migrado.

2b. A condição Criada Em igual a 2200-01-01 é adicionada à condição.

Porque é que os dados no meu campo DateTime mudam durante a migração?

Não existe nenhum campo de hora separado na Interface Unificada. Portanto, o campo DateTime mudará de um controlo de calendário para um campo de texto. A entrada deve estar num formato específico, conforme mostrado no campo de texto no exemplo a seguir.

Exemplo: campo DateTime

Vista de cliente Web de pré-migração

Legenda:

a. Campo Data e hora da pré-migração.

b. Campo Apenas data da pré-migração.

Vista da Interface Unificada pós-migração

Legenda:

a. Campo Data e hora de pós-migração.

b. Campo Apenas data de pós-migração.

Porque é que alguns dos meus campos de operadores estão em branco na Interface Unificada pós-migração?

Para tipos de dados de procura, apenas os operadores equal, not equal, null e not null são suportados na Interface Unificada e na ferramenta de migração. Os operadores Under e not-under não são suportados na Interface Unificada, pelo que não são suportados na ferramenta de migração. Quaisquer condições que tenham operadores under ou not-under são traduzidas como entidades relacionadas após a migração. São mostrados em branco na Interface Unificada e não podem ser editados.

Exemplo: Campos de operador Under e Not-under

Vista de cliente Web de pré-migração

Legenda:

a. OperadoresUnder.

Vista da Interface Unificada pós-migração

Legenda:

b. Campo do operador em branco.

Nota

As seguintes limitações são aplicáveis quando uma condição é definida no Hub de Suporte ao Cliente:

• O controlo de seletor de Data e Hora já não está disponível nas condições. No entanto, ainda pode editar a data e a hora no campo de texto.
• Apenas um nível da hierarquia da entidade relacionada é suportado. No entanto, pode selecionar entidades relacionadas e aninhadas na aplicação.
• A entidade relacionada dentro de um grupo da cláusula e/ou não é suportada.
• O operador Not-on para o tipo de dados Data não é suportado.
• Para o tipo de dados de Pesquisas, apenas os operadores equal, not equal, null e not null são suportados. Os operadores under e not-under não são suportados.

Posso migrar uma regra de novo depois de ter sido ativada?

• Para regras de criação automática de registos, sim. Pode migrar novamente uma regra ativada, mas primeiro deve desativá-la e eliminá-la da Interface Unificada.
• Para SLAs, não. Após a ativação de uma regra de SLA migrada, é associada a outra entidade (como um caso) ou está em uso. Por predefinição, uma regra ativada foi migrada com êxito. Antes de poder migrar uma regra ativada novamente, deve eliminá-la. No entanto, há uma limitação para as regras de SLA da Interface Unificada. Depois de uma regra ser associada a um caso ou entidade (ou seja, depois de ter sido ativada uma vez), não será possível eliminá-la, mesmo que esteja desativada. Portanto, a regra não pode ser migrada novamente se tiver sido previamente ativada ou aplicada.

Posso migrar regras de SLA padrão preteridas?

Não A ferramenta de migração apenas suporta regras de SLA avançadas. As regras padrão de SLA foram preteridas. Já não são suportadas na Interface Unificada, pelo que não são suportados na ferramenta de migração. Para mais informações, aceda a SLAs padrão no Dynamics 365 Customer Service estão preteridos.

Problemas conhecidos

Preterimento da propriedade do canal

Se usou alguma propriedade de canal na personalização de regras legadas, a ferramenta de migração não migrará essas regras com êxito. Não existe uma solução alternativa geral que possa ser aplicada para corrigir essa lacuna para todos os utilizadores. A solução alternativa depende muito de como usa as propriedades do canal nas regras legadas.

Diferença de comportamento quando a opção "Criar casos para atividades associadas a um caso resolvido" está selecionada

• Comportamento legado: Se o e-mail tiver um caso relacionado que foi resolvido desde o horário especificado, o caso resolvido será reativado por predefinição. Não é necessária qualquer personalização.
• Comportamento moderno: Se o e-mail tiver um caso relacionado que foi resolvido desde o horário especificado, é criado um novo caso por predefinição. A personalização é necessária para reativar um caso existente em vez de criar um novo caso.

Diferença de comportamento quando a opção "Criar caso se existir um direito válido para o cliente" estiver selecionada

• Comportamento legado: se o remetente do e-mail não tiver uma elegibilidade válida e o e-mail tiver um caso relacionado, o caso relacionado existente será atualizado.
• Comportamento moderno: Se o remetente do email não tiver uma elegibilidade válida, nenhum fluxo será invocado.

Lacunas de paridade entre fluxos de trabalho e fluxos do Power Automate (aplicável apenas à personalização de ações de itens de regra)

• As expressões "First not null" não podem ser migradas automaticamente. No entanto, a personalização pode ser aplicada manualmente ao fluxo de migração.
• O mapeamento do nome a apresentar do registo de pesquisa para um campo de cadeia não pode ser migrado automaticamente. No entanto, a personalização pode ser aplicada manualmente ao fluxo de migração.
• Os campos da parte da atividade usados como campos de origem não são suportados no fluxo.

Problemas conhecidos de fluxo

As regras migradas têm um caráter @ adicional para campos com o tipo de cadeia @

Se o fluxo de trabalho da regra de criação de relatórios automático legado for personalizado e tiver um caráter @ de texto simples num campo de cadeia, verá dois @, em vez de um na migração. Por exemplo, se adicionar um endereço de e-mail em texto simples no campo de descrição do caso, o caráter @será tratado como um caráter especial e migrado como @@.

Isto porque @ é identificado como um caráter especial para qualquer expressão dinâmica, tal como @triggerOutputs()?[body/_emailsender_value] no fluxo de migração.

A alternativa é remover manualmente o @ adicional no fluxo migrado.

A migração não suporta vários itens ou condições com o mesmo "aplicável quando" dentro do mesmo SLA

No cliente Web, vários itens podem ser definidos que têm a mesma condição "aplicável quando" e diferentes critérios de sucesso para um SLA. No entanto, a mesma capacidade não é suportada na Interface Unificada. Portanto, durante a migração, nenhum item de SLA subsequente desse tipo que tenha a mesma condição "aplicável quando" será criado.

As capturas de ecrã seguintes mostram o cenário que não é suportado na Interface Unificada. As duas condições "aplicáveis quando" mostradas têm critérios de sucesso diferentes.

Problemas de atributos do tipo de grupo de atividade durante a conversão de fluxo de trabalho para fluxo

Um atributo do tipo da parte da atividade atribuído a outro campo do tipo da parte da atividade não será migrado durante a conversão de fluxo de trabalho em fluxo, porque Power Automate atualmente não oferece suporte a este cenário. (Os campos mais comummente afetados são Para, De, CC e BCC em e-mails.) Embora a migração da regra não falhe, o valor dos dados para esses campos do tipo da parte da atividade que dependem de outro atributo do tipo da parte da atividade ficará em branco após a migração.

Exemplo: Atributos do tipo da parte da atividade

Vista de cliente Web de pré-migração

Legenda:

a. O campo De é um campo do tipo de parte da atividade a que é atribuído outro atributo do tipo da parte da atividade, {Bcc(E-mail)}. Ficará em branco após a migração.

b. O campo Para será migrado.

Vista da Interface Unificada pós-migração

Legenda:

b. Campo Para.

As verificações "First Not Null" em expressões nos fluxos de trabalho legado não são suportadas durante a conversão do fluxo de trabalho para o fluxo

Em fluxos de trabalho legados, um campo de pesquisa pode ser mapeado com múltiplas expressões onde verifica e atribui a expressão "First Not Null", como mostrado no exemplo do cliente Web que se segue. Uma vez que esta é uma limitação conhecida do estruturador de fluxos de trabalho legado, esta abordagem não é suportada como parte da conversão de fluxo de trabalho para fluxo. Portanto, o conversor do fluxo de trabalho atribui a primeira expressão sem realizar a verificação null. Em seguida, remove todas as expressões restantes, independentemente de terem valores não nulos. No exemplo que se segue, o fluxo só terá Regarding(Email) no campo Cliente neste passo.

Exemplo: expressões "First Not Null"

Vista pré-migração

Legenda:

a.Vista do cliente Web: No fluxo de trabalho, o campo Cliente tem {Regarding(Email); Contact(Create (Case)); Customer(Create (Case))}.

Na Interface Unificada, o campo Cliente só tem Regarding(Email), independentemente de ser nulo.

Importante

Se ainda estiver a ter problemas com a ferramenta de migração, contacte o administrador ou Suporte da Microsoft.

Consulte também

FAQ sobre a criação automática de registos moderna

Migrar regras de criação automática de registos e SLAs

Manual de Procedimentos de Migração do Dynamics 365 SLA e ARC