Perguntas frequentes sobre a ferramenta de migração
Ferramenta de migração para regras de criação automática de registros e acordos de nível de serviço (SLAs)
Quem pode acessar ou executar a ferramenta de migração?
Administradores e usuários com funções de gerente CSR podem executar a ferramenta de migração.
As regras migradas são ativadas automaticamente após a migração?
Não. Você deverá ativar manualmente as regras migradas depois que a migração for concluída.
Ainda posso usar minhas regras herdadas após o prazo de descontinuação?
Sim. As regras herdadas ativas continuarão sendo executadas depois do prazo de substituição até serem desativadas. No entanto, a experiência de edição e a capacidade de suporte param após a descontinuação.
Posso ativar uma regra com um status de migração "incompleta"?
Não. Uma regra migrada é ativada somente quando você alterna a opção Marcar como concluída para Sim após revisar uma regra incompleta e corrigir quaisquer problemas que estejam presentes. É quando a regra é considerada migrada com sucesso.
A regra herdada é desativada após a migração?
- Para criação automática de registros, sim. Ao ativar uma regra de criação de registros automática na Interface Unificada, a regra herdada correspondente é desativada.
- Para SLAs, não. Ao ativar uma regra de SLA migrada na Interface Unificada, a regra herdada correspondente permanecerá ativa porque as duas regras podem coexistir.
O que significa um status de migração "incompleto"?
- Na seção Resumo: o processo geral de migração não pôde concluir com êxito a migração de todas as regras selecionadas.
- Próximo de uma regra: a regra falhou ou não pôde ser totalmente migrada (ou seja, um ou mais itens ou condições não foram migrados).
Onde posso encontrar uma lista de regras parcialmente migradas rastreadas na ferramenta de migração?
As regras migradas parcialmente ou identificadas como migradas incompletamente não são consideradas totalmente migradas. Portanto, elas são rastreadas em Pendentes na seção Resumo. Apenas as regras que concluíram a migração com êxito são contadas em Migradas.
A ferramenta de migração oferece suporte a formulários ou campos personalizados?
- Para criação automática de registros, sim. A ferramenta de migração dá suporte a entidades, campos, atributos e configurações personalizados.
- Para SLAs, não. A ferramenta de migração não é totalmente compatível com entidades, campos, atributos e configurações personalizados. Para concluir a migração, os usuários devem modificar quaisquer fluxos de personalização, fluxos de trabalho, 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, acesse Quais são os direitos de uso do Microsoft Power Apps e do Power Automate para aplicativos do Dynamics 365?
Algumas das minhas regras estão incompletas ou parcialmente migradas. O que devo fazer?
Você pode usar os detalhes do problema para corrigir a regra no cliente Web e executar novamente a migração ou corrigir a regra migrada diretamente na Interface Unificada.
Posso executar novamente a ferramenta de migração para uma regra migrada específica?
Sim, você pode executar novamente a ferramenta de migração para uma regra migrada específica com base nos seguintes critérios:
- Para regras de migração incompletas ou com falha: selecione a mesma regra ao executar novamente a ferramenta de migração. A ferramenta substitui automaticamente a regra com falha ou incompleta existente pela regra recém-migrada.
- Para regras migradas com sucesso: exclua a regra migrada na Interface Unificada antes de executar novamente a ferramenta de migração.
Após a conclusão da migração, o que acontece com os registros de SLA existentes associados aos SLAs legados?
- Se o SLA herdado for desativado após a migração: o temporizador continuará em execução até o estado terminal desses registros de SLA. No entanto, as funcionalidades Resolver e Pausar não funcionarão.
- Se o SLA herdado ainda estiver no estado Ativo: os registros de SLA existentes associados aos SLAs herdados continuarão funcionando conforme o esperado.
- Se você quiser usar SLAs criados nos aplicativos Interface Unificada em registros existentes: você terá que atualizar manualmente o campo SLA para Interface Unificada SLA ou escrever o plug-in para atualizar os registros. 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 registros automáticos, vá até Perguntas frequentes sobre a criação automática moderna de registros.
Problemas conhecidos de conversão de condições
Esta seção descreve os principais cenários em que regras ou itens não concluirão a migração com êxito.
Se meus itens de regra ou condições tiverem entidades relacionadas dentro de uma cláusula de grupo aninhado (e/ou), eles serão migrados para a Interface Unificada?
Não. Atualmente, oferecemos suporte a apenas um nível da hierarquia de entidades relacionadas. Esses itens de regra ou condições só poderão ser migrados com êxito se você remover qualquer entidade relacionada na cláusula de grupo antes de migrar. Se você não tomar nenhuma ação, a regra falhará durante a etapa Verificação pré-migração. Se você optar por continuar a migração, a regra terá uma condição vazia para o item relacionado.
Exemplo: entidades relacionadas em uma cláusula de grupo aninhada
Exibição do cliente Web pré-migração
Legenda:
a. O título do item.
Exibição da Interface Unificada pós-migração
Legenda:
2a. "_FailedMigration" é acrescentado ao título do item migrado.
2b. O mesmo espaço reservado padrão, Criado em igual a 2200-01-01, é adicionado à condição.
Por que meus itens de regra ou condições com um campo DateType que usa um operador Not-On falham durante a verificação pré-migração e a migração real?
O operador Not-On do tipo de dados Data não é compatível com Interface Unificada. Portanto, não há suporte como parte da migração. Para corrigir esse problema, você pode alterar os itens ou condições herdados de {not-on selecteddate} para {selecteddate inferior a e selecteddate superior a} no cliente Web antes de executar novamente a ferramenta de migração para a regra correspondente.
Exemplo: campo DateType que usa um operador Not-On
Exibição do cliente Web pré-migração
Legenda:
a. O título do item.
Exibição da Interface Unificada pós-migração
Legenda:
2a. "_FailedMigration" é acrescentado ao título do item migrado.
2b. A condição Criado em igual a 2200-01-01 é adicionada à condição.
Por que os dados em meu campo DateTime são alterados durante a migração?
Não existe nenhum campo de hora separado em Interface Unificada. Portanto, o campo DateTime mudará de um controle de calendário para um campo de texto. A entrada deve estar em um formato específico, conforme mostrado no campo de texto no exemplo a seguir.
Exemplo: campo DateTime
Exibição do cliente Web pré-migração
Legenda:
a. Campo Data e hora pré-migração.
b. Campo Somente data pré-migração.
Exibição da Interface Unificada pós-migração
Legenda:
a. Campo Data e hora pós-migração.
b. Campo Somente data pós-migração.
Por que alguns dos meus campos de operador ficam em branco na Interface Unificada pós-migração?
Para tipos de dados de pesquisa, apenas os operadores equal, not equal, null e not null têm suporte na Interface Unificada e na ferramenta de migração. Os operadores Under e not-under não têm suporte na Interface Unificada e, portanto, não têm suporte na ferramenta de migração. Quaisquer condições que tenham operadores under ou not-under são traduzidos como entidades relacionadas após a migração. Eles são mostrados em branco em Interface Unificada e não podem ser editados.
Exemplo: campos de operador Under e not-under
Exibição do cliente Web pré-migração
Legenda:
a. operadores Under.
Exibição da Interface Unificada pós-migração
Legenda:
b. Campo do operador em branco.
Observação
As seguintes limitações são aplicáveis quando uma condição é definida no Hub do SAC:
- A controle seletor de Data e Hora não está mais disponível nas condições. No entanto, você ainda pode editar a data e a hora no campo de texto.
- Somente um nível da hierarquia de entidades relacionadas é compatível. No entanto, você pode selecionar entidades relacionadas e aninhadas no aplicativo.
- Não há suporte à entidade relacionada dentro de um grupo da cláusula and/or.
- O operador Not-on do tipo de dados Date não tem suporte.
- Para o tipo de dados Lookups, apenas os operadores equal, not equal, null e not null têm suporte. Não há suporte aos operadores under e not-under.
Posso migrar uma regra novamente após ela ser ativada?
- Para regras de criação automática de registros, sim. Você pode migrar uma regra ativada novamente, mas primeiro deve desativá-la e excluí-la da Interface Unificada.
- Para SLAs, não. Depois que uma regra de SLA migrada é ativada, ela é vinculada a outra entidade (como um caso ou está em uso). Por padrão, uma regra ativada foi migrada com êxito. Para migrar uma regra ativada novamente, você deve excluí-la. No entanto, há uma limitação para as regras de SLA 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 excluí-la, mesmo que esteja desativada. Portanto, a regra não poderá ser migrada novamente se já tiver sido ativada ou aplicada.
Posso migrar regras de SLA padrão preteridas?
Não. A ferramenta de migração só oferece suporte a regras de SLA aprimoradas. As regras padrão de SLA foram preteridas. Elas não têm mais suporte na Interface Unificada e, portanto, não têm suporte na ferramenta de migração. Para obter mais informações, acesse Os SLAs padrão no Dynamics 365 Customer Service foram preteridos.
Problemas conhecidos
Substituição de propriedade de canal
Se você usou alguma propriedade de canal na personalização de regras herdadas, 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 usuários. A solução alternativa depende muito de como você usa as propriedades do canal nas regras herdadas.
Diferença de comportamento quando a opção "Criar ocorrências para atividades associadas a uma ocorrência resolvida" está selecionada
- Comportamento herdado: se o email tiver um caso relacionado que foi resolvido desde o horário especificado, o caso resolvido será reativado por padrão. Nenhuma personalização é necessária.
- Comportamento moderno: se o email tiver um caso relacionado que foi resolvido desde o horário especificado, um novo caso será criado por padrão. A personalização é necessária para reativar um caso existente em vez de criar um caso.
Diferença de comportamento quando a opção "Criar caso se existir um direito válido para o cliente" estiver selecionada
- Comportamento herdado: se o remetente do email não tiver um direito válido e o email tiver um caso relacionado, o caso relacionado existente será atualizado.
- Comportamento moderno: se o remetente do email não tiver um direito válido, 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)
- Expressões "Primeiro não nulo" não podem ser migradas automaticamente. No entanto, a personalização pode ser aplicada manualmente ao fluxo de migração.
- O mapeamento do nome de exibição de um registro de pesquisa para um campo de cadeia de caracteres 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 de fluxo conhecidos
As regras migradas têm um caractere @ extra para campos com tipo de cadeia de caracteres @
Se o fluxo de trabalho da regra de criação do registro automático legado for personalizado e tiver um caractere @ de texto simples em um campo da cadeia de caracteres, você verá dois @, em vez de um na migração. Por exemplo, se você adicionar um endereço de email em texto simples no campo de descrição do caso, o caractere @ será tratado como um caractere especial e migrado como @@.
Isso acontece porque @ é identificado como um caractere especial para qualquer expressão dinâmica, como @triggerOutputs()?[body/_emailsender_value] no fluxo de migração.
A solução alternativa é remover manualmente o @ extra no fluxo migrado.
A migração não oferece suporte a vários itens ou condições com a mesma condição "aplicável quando" no mesmo SLA
No cliente Web, vários itens podem ser definidos com a mesma condição "aplicável quando" e diferentes critérios de êxito para um SLA. No entanto, o mesmo recurso não tem suporte na Interface Unificada. Portanto, durante a migração, nenhum item subsequente de SLA desse tipo com a mesma condição "aplicável quando" é criado.
As capturas de tela a seguir mostram o cenário que não tem suporte na Interface Unificada. As duas condições "aplicável quando" mostradas têm diferentes critérios de êxito.
Problemas de atributo de tipo de participante da atividade durante a conversão de fluxo de trabalho em fluxo
Um atributo de tipo de participante da atividade atribuído a outro campo de tipo de participante da atividade não será migrado durante a conversão de fluxo de trabalho em fluxo porque o Power Automate não oferece suporte a esse cenário no momento. (Os campos mais afetados são Para, De, CC e Cco em emails.) Embora a migração da regra não falhe, o valor dos dados para esses campos do tipo grupo de atividade que dependam de outro atributo do tipo grupo de atividade ficará em branco depois da migração.
Exemplo: atributos de tipo da parte da atividade
Exibição do cliente Web pré-migração
Legenda:
a. O campo De é um campo party–type de atividade que é atribuído a outro atributo party-type de atividade, {Bcc(Email)}. Ficará em branco depois da migração.
b. O campo Para será migrado.
Exibição da Interface Unificada pós-migração
Legenda:
b. campo Para.
Verificações "Primeiro Não Nulo" em expressões em fluxos de trabalho herdados não são compatíveis durante a conversão do fluxo de trabalho em fluxo
Nos fluxos de trabalho herdados, um campo de pesquisa pode ser mapeado com várias expressões em que você verifica e atribui a expressão "Primeiro Não Nulo", conforme mostrado no exemplo do cliente Web a seguir. Por causa de uma limitação conhecida no designer de fluxo de trabalho herdado, essa abordagem não é compatível como parte da conversão do fluxo de trabalho em fluxo. Portanto, o conversor de fluxo de trabalho atribui a primeira expressão sem realizar a verificação de nulos. Em seguida, remove todas as expressões restantes, independentemente de terem valores não nulos. No exemplo a seguir, o fluxo terá apenas Regarding(Email) no campo Cliente nesta etapa.
Exemplo: expressões "Primeiro Não Nulo"
Exibição pré-migração
Legenda:
a.Exibição do cliente Web: no fluxo de trabalho, o campo Cliente possui {Regarding(Email); Contact(Create (Case)); Customer(Create (Case))}.
Em Interface Unificada, o campo Cliente tem apenas Regarding(Email), independentemente de ser nulo.
Importante
Se você ainda estiver enfrentando problemas com a ferramenta de migração, entre em contato com o administrador ou com o Suporte da Microsoft.
Confira também
Perguntas frequentes sobre a criação de registros automática moderna
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de