Felsöka vanliga konfigurationsproblem med regler för automatisk skapande och uppdatering av poster

  • Artikel

Den här artikeln innehåller lösningar för vanliga scenarier med konfigurationsfel med regler för automatisk skapande och uppdatering av poster, på grund av vilka postskapande som kan misslyckas eller hoppas över.

Scenario 1

Exempel: Konfiguration av automatisk skapande och uppdateringsregel för arkivhandling

  • Alternativet Skapa kontakt för okänd avsändare bör väljas.
  • Ange villkorsvillkor till Alla inkommande e-postmeddelanden.
  • Lägg till åtgärd för att skapa ett ärende, välj Visa egenskaper och ange skiftlägesfälten per affärsanvändningsfall.

Fel 1 – "Ärendet saknar kund"

I fältet Kund i avsnittet ÄRENDEINFORMATION anges värdet för Avsändarkonto (Email) enligt nedan.

Skärmbild som visar hur värdet för Avsändarkonto (Email) anges i fältet Kund.

Den här inställningen resulterar i följande fel i systemjobb:

Ärendet saknar kund.

Skärmbild som visar information om felet som anger att ärendet saknar kunden.

Lösning för fel 1

Lös problemet genom att hålla fältet Kund tomt eller ange det till {Sender(Email)}. På så sätt kan systemet automatiskt skapa en kontakt för den okända avsändaren och länka den till ärendet.

Fel 2 – "Ett fel har inträffat"

Fältet Kund anges som {Avsändarkonto(Email)}, och fältet Kontakt anges som {Sender(Email)}.

Skärmbild som visar de värden som angetts för fälten Kund och Kontakt.

Den här inställningen resulterar i följande fel i systemjobb:

Ett fel har uppstått. Försök igen. Om problemet kvarstår kontrollerar du Microsoft Dynamics 365 Community för lösningar eller kontaktar organisationens Microsoft Dynamics 365-administratör. Slutligen kan du kontakta Microsoft Support.

Skärmbild som visar information om felet som uppstår på grund av värdet som angetts för fältet Kund.

Lösning för fel 2

Lös problemet genom att hålla fältet Kund tomt eller ange det till {Sender(Email)}. På så sätt kan systemet automatiskt skapa en kontakt för den okända avsändaren och länka den till ärendet.

Fel 3 – "Den angivna kontakten tillhör inte den kontakt som angavs i kundfältet."

Fälten Kund och Kontakt anges som {Sender(Email)}.

Skärmbild som visar värdet som angetts för fälten Kund och Kontakt.

Den här inställningen resulterar i följande fel i systemjobb:

Den angivna kontakten tillhör inte den kontakt som angavs i kundfältet. Ta bort värdet från kontaktfältet eller välj en kontakt som är associerad med den valda kunden och försök sedan igen.

Skärmbild som visar information om felet som anger att den angivna kontakten inte tillhör den kontakt som angavs i fältet Kund.

Lösning för fel 3

Lös problemet genom att lämna fältet Kontakt tomt och ange fältet Kund till tomt eller {Sender(Email)}.

Verifieringssteg

Du måste verifiera konfigurations- och valideringsstegen i följande tabell för att förstå huvudorsaken till problemet och lösa det.

Alternativ i Automatisk skapande av post och uppdateringsregel i Tjänsthantering Om markerat som Verifieringssteg Resultatet
Skapa ett ärende om det finns ett giltigt berättigande för kunden Ja Kontrollera att det finns en aktiv rättighet för kunden. Giltigt aktivt berättigande utvärderas enligt nedan:
– Om avsändaren av e-postmeddelandet är en kontakt med ett överordnat konto skapar Dynamics 365 kundtjänst ett ärende om kontaktens överordnade konto har ett giltigt berättigande och kontakten visas i avsnittet Kontakter i berättigandet
Eller,
- Om avsnittet Kontakter är tomt (vilket innebär att rättigheten gäller för alla kontakter för kunden)		 Ett ärende skapas.
Skapa ett ärende från ett e-postmeddelande som skickas av okända avsändare Ja För inkommande e-post från en okänd avsändare – Ett ärende skapas.
– En kontakt skapas också för den okända avsändaren.
Ja För ett inkommande e-postmeddelande med e-postadress till ett inaktivt konto eller en kontakt – Ett ärende skapas.
– Ett inaktivt konto eller en kontakt aktiveras.
Nej För ett inkommande e-postmeddelande med e-postadress för aktivt konto eller kontakt Ett ärende skapas.
Nej För ett inkommande e-postmeddelande som skickas av en annan posttyp än konto eller kontakt Inget ärende skapas.
Nej För ett inkommande e-postmeddelande med e-postadress till ett inaktivt konto eller en kontakt Inget ärende skapas.
Skapa ett ärende för aktiviteter som är associerade med ett löst ärende Ja För ett inkommande e-postmeddelande som är relaterat till ett löst ärende Ett ärende skapas.
Ja För ett inkommande e-postmeddelande som är relaterat till ett aktivt ärende Inget ärende skapas.

Scenario 2 – Användningen av {Regarding(Email)} i äldre miljö ger inte rätt data i flödet

Om du vill söka efter entiteten (antingen en kontakt eller ett konto) som skickar ett e-postmeddelande i äldre objekt för att skapa och uppdatera poster i kundtjänsten kan du använda den polymorfiska sökningen Avsändare (Email), som automatiskt hämtar lämplig entitet och visar entitetens namn. Polymorfa sökningar är sökningar där uppslagsmålet är mer än en typ av entitet. Den kan till exempel peka på antingen en kontakt eller ett konto. Men i moderna regler för automatisk skapande och uppdatering av poster stöds inte den här automatiska visningen, så du måste ange vilken typ av entitet du vill hämta tillsammans med fälten som ska visas från den entiteten.

Orsak

Ett flöde använder inte värdet {Regarding(Email)} som ett äldre arbetsflöde eftersom flödesuttryck refererar till ett datavärde från nyttolasten i föregående flödessteg. Om värdet {Regarding(Email)} till exempel är tomt när flödet börjar, förblir värdet i utlösarstegets nyttolast för {Regarding(Email)} tomt. Även om värdet {Regarding(Email)} uppdateras när ett ärende har skapats uppdateras data för e-postposter, men nyttolasten i flödet uppdateras inte. Så när värdet från nyttolasten refereras i efterföljande flödessteg förblir det tomt.

Åtgärd

Om värdet {Regarding(Email)} används i äldre regelobjekt måste du uppdatera det migrerade flödet manuellt för att använda "Incident-ID" eller "OData-ID". Använd "OData-ID" för fält som kräver entitetsreferens eller uppslag. Använd den skiftlägesspecifika identifieraren för fält som kräver GUID.

Scenario 3 – Problem med återgivning av polymorfa sökningar på fält som inte är uppslagsfält under migreringen från äldre till moderna regler för automatisk skapande och uppdatering av poster

Ett äldre objekt med regler för att skapa och uppdatera poster med polymorfa sökningar, till exempel Avsändare, resulterar i ett ogiltigt uppslag när det tilldelas till ett textfält.

I äldre objekt för att skapa och uppdatera regler för "automatisk arkivhandling" i kundtjänst kan du söka efter entiteten (antingen en kontakt eller ett konto) som skickade ett e-postmeddelande med polymorfisk sökning av avsändaren (Email), som automatiskt hämtar lämplig entitet och visar entitetens namn. Polymorfa sökningar är sökningar där uppslagsmålet är mer än en typ av entitet. Den kan till exempel peka på antingen en kontakt eller ett konto. I moderna regler för automatisk skapande och uppdatering av poster stöds dock inte den här automatiska visningen. Därför måste du ange vilken typ av entitet som du vill hämta tillsammans med fälten som ska visas från den entiteten.

Orsak

Det klassiska arbetsflödesbeteendet som används av äldre regler för automatisk skapande och uppdatering av poster har många dolda beteenden. Du kan till exempel automatiskt bestämma typen av entitet och hämta ett fält som visningsnamn om parametern används i en sträng, men returnera ID:t om det har tilldelats till ett uppslagsfält. Plattformsmigreringskoden som "regler för automatisk skapande och uppdatering av poster" använder vid konvertering från äldre till moderna arbetsflöden lägger inte till nödvändiga steg och fält.

Åtgärd

Lös problemet genom att

  • Uppdatera sökningen till en viss typ.
  • Använd ett annat fält på den inkommande entiteten som innehåller önskad text.