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