Vanliga frågor och svar om migreringsverktyg
Migreringsverktyg för automatiska postgenereringsregler och servicenivåavtal (SLA)
Vem kan komma åt eller köra migreringsverktyget?
Administratörer och användare som har CSR-chefsroller kan köra migreringsverktyget.
Aktiveras migrerade regler automatiskt efter migrering?
Nej Du måste aktivera migrerade regler manuellt när migreringen är slutförd.
Kan jag fortfarande använda mina tidigare regler efter tidsgränsen för utfasning?
Ja. Aktiva äldre regler fortsätter att köras efter utfasningsdeadline tills reglerna inaktiveras. Redigeringsupplevelsen och stödbarheten upphör dock efter utfasning.
Kan jag aktivera en regel som har migreringsstatusen "ofullständig"?
Nej En migrerad regel aktiveras endast när du byter växlingsknappen Markera som komplett till Ja efter att du har granskat en ofullständig regel och åtgärdat eventuella problem som finns. Det är då regeln anses vara framgångsrik migrerad.
Blir den äldre regeln inaktiverad efter att jag har migrerat?
- Ja, för att skapa poster automatiskt. När du aktiverar en migrerad automatisk postgenerering i enhetligt gränssnitt inaktiveras motsvarande äldre regel.
- Inte för SLA. När du aktiverar en migrerad SLA-regel i enhetligt gränssnitt förblir motsvarande äldre regel aktiv eftersom de båda reglerna kan samexistera.
Vad betyder en "oavslutad" migreringsstatus?
- I sammanfattningsavsnittet: Den övergripande migreringsprocessen kunde inte slutföra migreringen för saltliga valda regler.
- Bredvid en regel: Antingen har regelnmisslyckats eller också kunde den inte migreras helt (det vill säga, en eller flera objekt eller villkor kunde inte migreras).
Var hittar jag en lista över delvis migrerade regler som spåras i migreringsverktyget?
Regler som är delvis migrerade, eller som identifieras som ofullständigt migrerade, anses inte vara helt migrerade. Därför spåras de under Väntande i avsnittet Sammanfattning. Endast regler som har fullföljt migreringen räknas under Migrerade.
Stöder migreringsverktyget anpassade formulär eller fält?
- Ja, för att skapa poster automatiskt. Migreringsverktyget stöder anpassade entiteter, fält, attribut och konfigurationer.
- Inte för SLA. Migreringsverktyget stöder inte anpassade entiteter, fält, attribut och konfigurationer fullt ut. För att slutföra migreringen måste användare ändra befintliga anpassningsflöden, arbetsströmmar, plugins eller annan anpassad kod på de anpassade enheterna, fälten, attributen och konfigurationerna.
Behöver jag en separat licens för Power Automate innan jag kör migreringen?
Nej Mer information om licensens riktlinjer finns i Vad är Microsoft Power Apps- och Power Automate-användarrättigheter för Dynamics 365-program?
Vissa av mina regler är ofullständiga eller delvis migrerade. Vad ska jag göra?
Du kan antingen använda probleminformationen för att rätta till regeln i webbklienten och sedan köra migreringen igen, eller åtgärda den migrerade regeln direkt i enhetligt gränssnitt.
Kan jag köra migreringsverktyget för en specifik migrerad regel igen?
Ja, du kan köra migreringsverktyget för en specifik migrerad regel igen utifrån följande kriterier:
- För ofullständiga regler eller regler som inte kunnat migreras: Välj samma regel när du kör migreringsverktyget igen. Verktyget ersätter automatiskt befintlig ofullständig eller ofullständig regel med den nyligen migrerade regeln.
- För regler som har migrerats korrekt: Ta bort den migrerade regeln enhetligt gränssnitt innan du kör migreringsverktyget igen.
När migreringen är klar, vad händer med befintliga SLA-poster som är associerade med äldre SLA?
- Om den äldre SLA:n är inaktiverad efter migrering: Timern fortsätter att köras tills sluttillståndet för sådana SLA-poster inträffar. Funktionerna Lös och Pausa fungerar emellertid inte.
- Om den äldre SLA:n fortfarande är i ett aktivt tillstånd: Befintliga SLA-poster som är associerade med äldre SLA kommer att fortsätta att fungera som förväntat.
- Om du vill använda SLA som skapats i enhetligt gränssnitt-programmen i befintliga poster: Du måste manuellt uppdatera SLA-fältet till SLA för enhetligt gränssnitt eller skriva insticksprogrammet för att uppdatera posterna. Logiken för insticksprogram kan till exempel vara Modernt flöde eller arbetsflöde.
För information om migrerade regler eller flöden i modernt automatisk postskapande, gå till Vanliga frågor och svar om modernt automatiskt postskapande.
Kända problemkonverteringar
Detta avsnitt beskriver viktiga situationer där regler eller objekt inte slutför migreringen.
Om mina regelobjekt eller villkor har relaterade entiteter i en kapslad gruppsats (och/eller), migreras de till enhetligt gränssnitt?
Nej För närvarande stöds endast en (1) nivå för den relaterade entitetshierarkin. Sådana regelobjekt eller villkor kan migreras endast om du tar bort alla relaterade entiteter i gruppsatsen innan du migrerar. Om du inte vidtar någon åtgärd kommer regeln att misslyckas under steget för förmigreringskontroll. Om du väljer att fortsätta med migreringen kommer regeln att ha ett tomt villkor för det relaterade objektet.
Exempel: Relaterade entiteter i en kapslad gruppsats
Webbklientvy före migrering
Förklaring:
a. Objektets rubrik.
Enhetlig gränssnittsvy efter migrering
Förklaring:
2a. "_FailedMigration" läggs till i rubriken för det migrerade objektet.
2b. Samma standardplatshållare, skapades med Lika med 2200-01-01, läggs till i villkoret.
Varför misslyckas mina regelobjekt eller villkor med ett DateType-fält där en "Inte på"-operator används vid kontroll före migrering och den faktiska migreringen?
Operatorn Inte på för datatypen Datum stöds inte i enhetligt gränssnitt. Därför stöds det inte som en del av migreringen. Du kan åtgärda det här problemet genom att ändra de äldre objekten eller villkoren från {not-on selectdate} till {selecteddate mindre än selecteddate större än} i webbklienten innan du kör om migreringsverktyget för motsvarande regel.
Exempel: DateType-fält som använder en Not-On-operator
Webbklientvy före migrering
Förklaring:
a. Objektets rubrik.
Enhetlig gränssnittsvy efter migrering
Förklaring:
2a. "_FailedMigration" läggs till i rubriken för det migrerade objektet.
2b. Villkoret Skapat med Lika med 2200-01-01 läggs till i villkoret.
Varför ändras informationen i mitt DateTime-fält vid migreringen?
Det finns inget separat tidsfält i enhetligt gränssnitt. Därför kommer fältet DateTime att ändras från en kalenderkontroll till ett textfält. Indata ska vara i ett specifikt format som visas i textrutan i följande exempel:
Exempel: fältet DateTime
Webbklientvy före migrering
Förklaring:
a. Förmigreringsfältet Datum och tid.
b. Förmigreringsfältet Endast datum.
Enhetlig gränssnittsvy efter migrering
Förklaring:
a. Eftermigreringsfältet Datum och tid.
b. Eftermigreringsfältet Endast datum.
Varför är vissa av mina operatorsfält tomma i enhetligt gränssnitt efter migrering?
För sökningsdatatyperna stöds endast operatorerna lika med, ej lika med, nullnot equal, noll samt ej noll i det enhetliga gränssnittet samt i migreringsverktyget. Operatorerna under och ej under stöds inte i enhetligt gränssnitt och stöds därför heller inte i migreringsverktyget. Alla villkor som har operatorer av typen under eller ej under översätts till relaterade enheter efter migrering. De visas som tomma i enhetligt gränssnitt och kan inte redigeras.
Exempel: Operatorsfält under och ej under
Webbklientvy före migrering
Förklaring:
a.Under operatorer.
Enhetlig gränssnittsvy efter migrering
Förklaring:
b. Tomt operatorsfält.
Kommentar
Följande begränsningar gäller när ett villkor definieras i Kundtjänstnav:
- Väljarkontrollen för datum och tid är inte längre tillgänglig i villkoren. Du kan emellertid fortfarande redigera datum och tid i textfältet.
- Endast en nivå för den relaterade entitetshierarkin stöds. Du kan emellertid välja kapslade, relaterade entiteter i programmet.
- Den relaterade entiteten i en grupp tillhörande klausulen och/eller stöds inte.
- Operatorn Inte på för datatypen Datum stöds inte.
- För datatypen Sökningar städs enbart operatorerna lika med, ej lika med, noll samt ej noll. Operatorerna under och ej under stöds inte.
Kan jag migrera en regel igen när den har aktiverats?
- Ja, för automatiska regler för att skapa poster. Du kan migrera en aktiverad regel igen, men först måste du inaktivera och ta bort den från det enhetliga gränssnittet.
- Inte för SLA. När en migrerad SLA-regel har aktiverats länkas den till en annan entitet (t.ex. ett ärende) eller också används den. Som standard har en aktiverad regel migrerats. Innan du kan migrera en aktiverad regel igen måste du ta bort den. Det finns emellertid en begränsning för SLA-regler för enhetligt gränssnitt. Efter att en regel har associerats med ett ärende eller en entitet (det vill säga efter att den har aktiverats en gång) kan du inte ta bort den, även om den är inaktiverad. Det går därför inte att migrera regeln igen om den tidigare har aktiverats eller tillämpats.
Kan jag migrera inaktuella standardregler för SLA-avtal?
Nej Migreringsverktyget har endast stöd för utökade SLA-regler. SLA-standardregler har fasats ut. De stöds inte längre i det enhetliga gränssnittet och stöds därför inte i migreringsverktyget. Mer information finns i Standard-SLA i Dynamics 365 Customer Service är inaktuella.
Kända problem
Utfasning av kanalegenskap
Om du har använt några kanalegenskaper i anpassningen av äldre regler kommer migreringsverktyget inte att migrera dessa regler. Det finns ingen allmän lösning som kan tillämpas för att åtgärda denna lucka för alla användare. Lösningen beror mycket på hur du använder kanalegenskaperna i de äldre reglerna.
Beteendeskillnad när alternativet "Skapa ärenden för aktiviteter som är kopplade till ett stängt ärende" väljs
- Äldre beteende: Om e-postmeddelandet har ett relaterat ärende som har lösts sedan den angivna tidpunkten återaktiveras det lösta ärendet som standard. Ingen anpassning krävs.
- Modernt beteende: Om e-postmeddelandet har ett relaterat ärende som har lösts sedan den angivna tidpunkten skapas ett nytt ärende som standard. Anpassning krävs för att återaktivera ett befintligt ärende i stället för att skapa ett nytt ärende.
Beteendeskillnad när alternativet "Skapa ärende om ett giltigt berättigande finns för kunden" är valt
- Äldre beteende: Om e-postavsändaren inte har ett giltigt berättigande och e-postmeddelandet har ett relaterat ärende, uppdateras det befintliga relaterade ärendet.
- Modernt beteende: Om e-postavsändaren inte har ett giltigt berättigande anropas inget flöde.
Paritetsgap mellan arbetsströmmar och Power Automate-flöden (gäller endast för anpassning av regelobjektåtgärder)
- "Först inte null"-uttryck kan inte migreras automatiskt. Anpassning kan emelelrtid tillämpas manuellt på flödet för migreringen.
- Mappningen av en sökningsposts visningsnamn till ett strängfält kan inte migreras automatiskt. Anpassning kan emelelrtid tillämpas manuellt på flödet för migreringen.
- Aktivitetspartfält som används som källfält stöds inte i flödet.
Kända flödesproblem
Migrerade regler har ett extra @-tecken för fält med @ strängtyp
Om det gamla arbetsflödet för automatisk postgenerering har anpassats och det har en oformaterad text @ tecken i ett strängfält visas två @, i stället för ett vid migrering. Om du till exempel lägger till en e-postadress i oformaterad text i ärendebeskrivningsfältet behandlas @-tecknet som ett specialtecken och migreras som @@.
Detta beror på att @identifieras som ett specialtecken för något dynamiskt uttryck, till exempel @triggerOutputs()?[body/_emailsender_value] i migreringsflödet.
Lösningen är att manuellt ta bort det extra @ i det migrerade flödet.
Migreringen stöder inte flera objekt eller villkor som har samma "Tillämpligt när" i samma SLA
I webbklienten kan flera objekt definieras som har samma "tillämpligt om"-villkor olika framgångskriterier för ett SLA. Samma funktion stöds emellertid inte i enhetligt gränssnitt. Under migreringen skapas därför inga efterföljande SLA-objekt av denna typ med samma "Tillämpligt när"-villkor.
Följande skärmdumpar visar scenariet som inte stöds i enhetligt gränssnitt. De två "Tillämpligt när"-villkor som visas har olika framgångskriterier.
Problem med aktivitets parttyp attribut under arbetsflödet för att flöda omvandling
Ett attribut av aktivitetspartyp som tilldelas till ett annat fält av aktivitetspartytyp migreras inte under konvertering av arbetsflöde till flöde, detta eftersom Power Automate för närvarande inte stöder inte detta scenario. (De vanligaste fälten som påverkas är fälten Till, Från, CC och BCC i e-postmeddelanden.) Även om migreringen av regeln inte kommer att misslyckas kommer datavärdet för sådana fält av aktivitetsparttyp som förlitar sig på ett annat attribut av typen aktivitetspart att vara tomt efter migreringen.
Exempel: Aktivitetspartattribut
Webbklientvy före migrering
Förklaring:
a. Fältet Från är ett fält av aktivitetsparttyp som tilldelas ett annat attribut av typen aktivitetspart, {Bcc(Email)}. Det kommer att vara tomt efter migrering.
b. Fältet Till migreras.
Enhetlig gränssnittsvy efter migrering
Förklaring:
b.Till-fält.
"Första icke-noll"-kontroller i uttryck inom ett äldre arbetsströmmar stöds inte vid konvertering arbetsflöde-till flöde
I äldre arbetsströmmar kan ett sökningsfält mappas med flera uttryck där du kontrollerar och tilldelar ett "första ej noll"-uttryck enligt följande exempel. På grund av en känd begränsning i den äldre arbetsflödesdesignern stöds denna metod inte som en del av konverteringen arbetsflöde-till-flöde. Därför tilldelar arbetsflödesomvandlaren det första uttrycket utan att utföra nollkontrollen. Den tar sedan bort alla återstående uttryck, oavsett om dessa har icke-nullvärden. I det exempel som följer kommer flödet endast ha Regarding(Email) i fältet Kund i detta steg.
Exempel: "Första ej noll"-uttryck
Förmigreringsvy
Förklaring:
a.Webbklientvy: I arbetsflödet har fältet Kund {Regarding(Email); Contact(Create (Case)); Customer(Create (Case))}.
I det enhetliga gränssnittet har fältet Kund endast Regarding(Email), oavsett om detta är "noll".
Viktigt!
Om du fortfarande har problem med migreringsverktyget kan du kontakta din administratör eller Microsoft Support.
Se även
Vanliga frågor och svar om modern postgenerering