Dela via

Felsöka vanliga konfigurationsproblem med automatisk postgenerering och uppdateringsregler

  • Artikel

Den här artikeln innehåller lösningar för vanliga konfigurationsfelscenarier 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 regel för automatisk skapande och uppdatering av poster

  • Alternativet Skapa kontakt för okänd avsändare bör väljas.
  • Ange villkorskriterier för all inkommande e-post.
  • 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ändares konto (e-post) enligt nedan.

Skärmbild som visar hur värdet för Avsändares konto (e-post) 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ändares konto(e-post)}, 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 inträffat. Försök igen. Om problemet kvarstår kontrollerar du Microsoft Dynamics 365-community efter 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 som 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.

Alternativet Regler för att skapa och uppdatera poster automatisk i servicehantering Om vald som Verifieringssteg Resultat
Skapa ett ärende om det finns ett giltigt berättigande för kunden Ja Validera att det fins ett giltigt berättigande för kunden. Giltig aktiv 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 en giltig behörighet och kontakten visas i avsnittet Kontakter i berättigandet
Eller,
- Om avsnittet Kontakter är tomt (vilket innebär att berättigandet gäller för alla kontakter för kunden)		 Ett ärende skapas.
Skapa ett ärende från ett e-postmeddelande som skickats av okända avsändare Ja För alla inkommande e-postmeddelande från en okänd avsändare – Ett ärende skapas.
– En kontakt skapas också för den okända avsändaren.
Ja För inkommande e-post med e-postadress för inaktivt konto eller en kontakt – Ett ärende skapas.
– Ett inaktivt konto eller en kontakt aktiveras.
Nej För inkommande e-post med e-postadress för aktivt konto eller en kontakt Ett ärende skapas.
Nej För inkommande e-post skickat av andra posttyper än konto eller en kontakt Inget ärende skapas.
Nej För inkommande e-post med e-postadress för inaktivt konto eller en kontakt Inget ärende skapas.
Skapa ett ärende för aktiviteter som är kopplade till ett stängt ärende Ja För inkommande e-post som är relaterad till ett stängt ärende Ett ärende skapas.
Ja För inkommande e-post som är relaterad till ett aktivt ärende Inget ärende skapas.

Scenario 2 – Användning av {Regarding(Email)} i äldre funktioner 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 kan du använda polymorf sökningen Avsändare (e-post) i äldre objekt som skickar ett e-postmeddelande, som automatiskt hämtar rätt entitet och visar entitetens namn. Polymorfisk uppslag är uppslag där målet för uppslaget är mer än en typ av entitet. Den kan till exempel peka på 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, så du måste ange vilken typ av entitet som 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 ett av det föregående flödesstegets nyttolast. Om till exempel värdet {Regarding(Email)} är tomt när flödet börjar kommer värdet i utlösarstegets nyttolast för {Regarding(Email)} att förbli 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 de efterföljande flödesstegen förblir det tomt.

Åtgärd

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

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

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

Om du vill söka efter entiteten (antingen en kontakt eller ett konto) som har skickat ett e-postmeddelande kan du använda polymorfa uppslag för avsändaren (e-post) i äldre objekt som skickat ett e-postmeddelande, som automatiskt hämtar rätt entitet och visar entitetens namn. Polymorfisk uppslag är uppslag där målet för uppslaget är mer än en typ av entitet. Den kan till exempel peka på 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 returneraR ID:t om det tilldelas till ett uppslagsfält. Den plattformsmigreringskod som "regler för automatisk skapande och uppdatering av poster" använder när du konverterar 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 uppslagstypen.
  • Använd ett annat fält för den inkommande entiteten som innehåller den önskade texten.