Siirtotyökalun usein kysytyt kysymykset

Tietueiden automaattisen luonnin sääntöjen ja palvelutasosopimusten siirtotyökalu

Kuka voi käyttää siirtotyökalua tai suorittaa sen?

Järjestelmänvalvojat ja käyttäjät, joille on määritetty CSR-esimiehen roolit, voivat käyttää siirtotyökalua.

Aktivoidaanko siirretyt säännöt automaattisesti siirron jälkeen?

Ei. Siirretyt säännöt on aktivoitava manuaalisesti siirron valmistumisen jälkeen.

Voinko edelleen käyttää vanhoja sääntöjäni vanhentumisen määräpäivän jälkeen?

Kyllä. Aktiivisia vanhoja sääntöjä käytetään vanhentumisen määräpäivän jälkeen siihen asti, kun niiden aktivointi on poistettu. Muokkauskokemus ja tuettavuus päättyvät kuitenkin vanhentumisen jälkeen.

Voinko aktivoida säännön, jonka siirron tila on Keskeneräinen?

Ei. Siirretty sääntö aktivoidaan vain, kun Merkitse valmiiksi -vaihtopainikkeen arvoksi muutetaan Kyllä epätäydellisen säännön tarkistamisen ja säännön mahdollisten ongelmien korjaamisen jälkeen. Tällöin säännön siirron katsotaan onnistuneen.

Poistetaanko vanhan säännön aktivointi siirron jälkeen?

• Kyllä, jos kyse on tietueiden automaattisesta luonnista. Kun siirretty tietueiden automaattisen luonnin sääntö aktivoidaan Unified Interfacessa, vastaavan vanhan säännön aktivointi poistetaan.
• Ei, jos kyse on SLA-kohteesta. Kun siirretty SLA-sääntö aktivoidaan Unified Interfacessa, vastaava vanha sääntö jää aktiiviseksi, sillä molemmat säännöt voivat olla aktiivisia.

Mitä siirron Keskeneräinen-tila tarkoittaa?

• Yhteenveto-osassa: Kaikkien valittujen sääntöjen siirto ei valmistunut siirtoprosessin aikana.
• Säännön vieressä: Sääntö on joko epäonnistunut tai sitä ei voitu siirtää kokonaan (eli vähintään yhden kohteen tai ehdon siirto epäonnistui).

Missä on luettelo siirtotyökalun seuraamista osittain siirretyistä säännöistä?

Sääntöjä, jotka on siirretty osittain tai jotka on tunnistettu epätäydellisesti siirretyiksi, ei pidetä täysin siirrettyinä. Siksi niitä seurataan Yhteenveto-osan Odottaa-kohdassa. Siirretyt-kohtaan otetaan mukaan vain säännöt, joiden siirto onnistui täysin.

Tukeeko siirtotyökalu mukautettuja lomakkeita tai kenttiä?

• Kyllä, jos kyse on tietueiden automaattisesta luonnista. Siirtotyökalu tukee mukautettuja entiteettejä, kenttiä, määritteitä ja määrityksiä.
• Ei, jos kyse on SLA-kohteesta. Siirtotyökalu ei tue täysin mukautettuja entiteettejä, kenttiä, määritteitä ja määrityksiä. Jotta siirto voidaan tehdä valmiiksi, käyttäjien on muokattava olemassa olevia mukautuksen työnkulkuja, laajennuksia ja muuta mukautettua koodia mukautetuissa entiteeteissä, kentissä, määritteissä ja määrityksissä.

Tarvitsenko erillisen Power Automate -käyttöoikeuden ennen siirron suorittamista?

Ei. Lisätietoja käyttöoikeuksista on kohdassa Millaiset Microsoft Power Appsin ja Power Automaten käyttöoikeudet Dynamics 365 -sovelluksilla on?

Osa säännöistä siirrettiin epätäydellisesti tai osittain. Mitä minun tulisi tehdä?

Voit korjata säännön verkkoasiakasohjelmassa ongelman tietojen perusteella ja suorittaa siirron uudelleen tai korjata siirretyn säännön suoraan Unified Interfacessa.

Voinko suorittaa siirtotyökalun uudelleen tietyn siirretyn säännön osalta?

Kyllä. Voit suorittaa siirtotyökalun uudelleen tietyn siirretyn säännön osalta seuraavien ehtojen perusteella:

• Keskeneräiset säännöt tai säännöt, joiden siirto epäonnistui: Valitse sama sääntö, kun suoritat siirtotyökalun uudelleen. Työkalu korvaa automaattisesti aiemmin luodun keskeneräisen tai epäonnistuneen säännön uudella siirretyllä säännöllä.
• Sääntöjen siirron onnistumiseksi: Poista siirretty sääntö Unified Interfacessa ennen siirtotyökalun suorittamista uudelleen.

Mitä siirron suorittamisen jälkeen tapahtuu aiemmin luoduille SLA-tietueille, jotka on liitetty vanhoihin SLA-kohteisiin?

• Jos vanhan SLA:n aktivointi on poistettu siirron jälkeen: Ajastimen suorittamista jatketaan, kunnes näiden SLA-tietueiden päätetila saavutetaan. Ratkaise- ja Keskeytä-toiminnot eivät kuitenkaan toimi.
• Jos vanha SLA on yhä Aktiivinen-tilassa: Aiemmin luodut SLA-tietueet, jotka on liitetty vanhoihin SLA-kohteisiin, jatkavat toimimista odotetulla tavalla.
• Jos haluat käyttää Unified Interface -sovelluksissa käytettyjä SLA-kohteita aiemmin luoduissa tietueissa: Päivitä SLA-kenttä manuaalisesti Unified Interface SLA:ksi tai kirjoita laajennus, joka päivittää tietueet. Laajennuksen logiikka voi olla esimerkiksi Moderni työnkulku tai Työnkulku.

Lisätietoja siirretyistä säännöistä ja työnkuluista modernissa tietueiden automaattisessa luonnissa on kohdassa Usein kysyttyjä kysymyksiä tietueiden automaattisesta luomisesta.

Tunnetut ehdon muunto-ongelmat

Tässä osassa kerrotaan tärkeistä skenaarioista, joissa sääntöjen tai kohteiden siirto ei onnistu.

Jos säännön kohteilla tai ehdoilla on liittyviä entiteettejä sisäkkäisessä ryhmälauseessa (ja/tai), siirretäänkö ne Unified Interfaceen?

Ei. Tällä hetkellä tuetaan yhtä liittyvän entiteettihierarkian tasoa. Tällaisten sääntökohteiden tai -ehtojen siirron onnistuminen edellyttää, että liittyvät entiteetit poistetaan ryhmälauseesta ennen siirtoa. Jos mitään ei tehdä, sääntö epäonnistuu siirtoa edeltävän tarkastusvaiheen aikana. Jos päätät jatkaa siirtoa, säännössä on tyhjä ehto liittyvää kohdetta varten.

Esimerkki: Liittyvät entiteetit sisäkkäisessä ryhmälauseessa

Siirtoa edeltävän WWW-asiakasohjelman näkymä

Selite:

a. Kohteen otsikko.

Siirron jälkeinen Unified Interface -näkymä

Selite:

2a. Siirretyn kohteen otsikkoon loppuun liitetään teksti _FailedMigration.

2b. Sama Luotu on sama kuin 2200-01-01 -vakiopaikkamerkki lisätään ehtoon.

Miksi säännön kohteet tai ehdot, joissa on ei-operaattoria käyttävä Datetype-kenttä, ei läpäise siirtoa edeltävää tarkistusta ja sen siirto epäonnistuu?

Päivämäärä-tietotyypin Ei-operaattoria ei tueta Unified Interfacessa. SIksi sitä ei tueta siirron osana. Tämän ongelman voi korjata muuttamalla verkkoasiakasohjelmassa vanhojen kohteiden tai ehtojen arvon {not-on selecteddate} arvoksi {selecteddate less than and selecteddate greater than} ennen siirtotyökalun suorittamista uudelleen vastaavan säännön osalta.

Esimerkki: DateType-kenttä, joka käyttää Ei-operaattoria

Siirtoa edeltävän WWW-asiakasohjelman näkymä

Selite:

a. Kohteen otsikko.

Siirron jälkeinen Unified Interface -näkymä

Selite:

2a. Siirretyn kohteen otsikkoon loppuun liitetään teksti _FailedMigration.

2b. Luotu on sama kuin 2200-01-01 -ehto lisätään ehtoon.

Miksi DateTime-kentän tiedot muuttuivat siirron aikana?

Unified Interfacessa ei ole erillisiä aikakenttiä. Siksi DateTime-kenttä muuttuu kalenterin ohjausobjektista tekstikentäksi. Syötteenä on käytettävä tiettyä muotoa alla olevassa esimerkissä olevan tekstin mukaan.

Esimerkki: DateTime-kenttä

Siirtoa edeltävän WWW-asiakasohjelman näkymä

Selite:

a. Siirtoa edeltävä Päivämäärä ja aika -kentän sijainti.

b. Siirtoa edeltävä Vain päivämäärä -kentän sijainti.

Siirron jälkeinen Unified Interface -näkymä

Selite:

a. Siirron jälkeinen Päivämäärä ja aika -kenttä.

b. Siirron jälkeinen Vain päivämäärä -kenttä.

Miksi jotkin operaattorikentistä ovat tyhjiä Unified Interfacessa siirron jälkeen?

Valintatietotyypeistä vain operaattoreita sama kuin, eri kuin, tyhjäarvo ja ei tyhjäarvo tuetaan Unified Interfacessa ja siirtotyökalussa. Operaattoreita alle ja ei alle ei tueta Unified Interfacessa, joten niitä ei tueta myöskään siirtotyökalussa. Kaikki ehdot, joilla on alle- tai ei alle -operaattoreita, käännetään liittyviksi entiteeteiksi siirron jälkeen. Ne näkyvät tyhjinä Unified Interfacessa, eikä niitä voi muokata.

Esimerkki: Alle- ja ei alle -operaattorikentät

Siirtoa edeltävän WWW-asiakasohjelman näkymä

Selite:

a.Alle-operaattorit.

Siirron jälkeinen Unified Interface -näkymä

Selite:

b. Tyhjä operaattorikenttä.

Muistiinpano

Seuraavat rajoitukset ovat käytössä, kun ehto on määritetty asiakaspalvelukeskuksessa seuraavasti:

• Päivämäärän ja kellonajan valitsin -ohjausobjektia ei voi enää käyttää ehdoissa. Voit kuitenkin edelleen muokata päivämäärää ja aikaa tekstikentässä.
• Vain yhtä liittyvän entiteettihierarkian tasoa tuetaan. Voit kuitenkin valita sovelluksessa sisäkkäisiä liittyviä entiteettejä.
• Liittyvää entiteettiä ja/tai-lausekkeen ryhmässä ei tueta.
• Päivämäärä-tietotyypin Ei-operaattoria ei tueta.
• Haut-tietotyypissä tuetaan vain sama kuin-, eri kuin-, tyhjäarvo- ja ei tyhjäarvo-operaattoreita. Alle- ja ei alle-operaattoreita ei tueta.

Voinko siirtää säännön uudestaan sen jälkeen, kun se on aktivoitu?

• Kyllä, jos kyse on tietueiden automaattisen luonnin säännöistä. Aktivoidun säännön voi siirtää uudelleen, mutta sen aktivointi on ensin poistettava ja sääntö on poistettava Unified Interfacesta.
• Ei, jos kyse on SLA-kohteesta. Kun SLA-sääntö on aktivoitu, se on linkitetty toiseen entiteettiin (kuten palvelupyyntöön) tai on käytössä. Oletus on, että aktivoitu sääntö on siirretty onnistuneesti. Ennen kuin voit siirtää aktivoidun säännön uudelleen, sinun on poistettava se. Unified Interfacen SLA-säännöissä on kuitenkin rajoitus. Kun sääntö on liitetty palvelupyyntöön tai entiteettiin (eli sen jälkeen, kun se on aktivoitu kerran), sitä ei voi enää poistaa, vaikka sen aktivointi olisi poistettu. Niinpä sääntöä ei voi siirtää uudelleen, jos se on aiemmin aktivoitu tai sitä on käytetty.

Voiko vanhentuneita palvelutasosopimuksen vakiosääntöjä siirtää?

Ei. Siirtotyökalu tukee vain parannettuja SLA-sääntöjä. SLA-vakiosäännöt ovat vanhentuneet. Niitä ei enää tueta Unified Interfacessa, eikä niitä sen vuoksi tueta myöskään siirtotyökalussa. Lisätietoja on kohdassa Dynamics 365 Customer Servicen vakio-SLA:t vanhentuvat.

Tunnetut ongelmat

Kanavan ominaisuuden vanhentuminen

Jos olet käyttänyt vanhojen sääntöjen mukauttamisessa kanavan ominaisuuksia, siirtotyökalu ei voi siirtää kyseisiä sääntöjä. Tämän puutteen korjaamiseksi ei ole yleistä ratkaisua, joka toimisi kaikille käyttäjille. Ratkaisu riippuu siitä, miten vanhoissa säännöissä käytetään kanavan ominaisuuksia.

Ero toimintatavassa, kun Luo palvelupyyntöjä ratkaistuun palvelupyyntöön liittyville aktiviteeteille -vaihtoehto on valittuna

• Vanha toimintatapa: Jos sähköpostiviestillä on liittyvä palvelupyyntö, joka on ratkaistu tietyn ajan jälkeen, ratkaistu palvelupyyntö aktivoidaan uudelleen oletusarvoisesti. Mukauttamista ei tarvita.
• Moderni toimintatapa: Jos sähköpostiviestillä on liittyvä palvelupyyntö, joka on ratkaistu tietyn ajan jälkeen, luodaan uusi palvelupyyntö oletusarvoisesti. Mukauttaminen on pakollinen, jotta aiemmin luotu palvelupyyntö voidaan aktivoida uudelleen eikä luoda uutta palvelupyyntöä.

Ero toimintatavassa, kun Luo palvelupyyntö, jos asiakkaalla on kelvolliset oikeudet -vaihtoehto on valittuna

• Vanha toimintatapa: Jos sähköpostiviestin lähettäjällä ei ole kelvollisia oikeuksia ja sähköpostiviestillä on liittyvä palvelupyyntö, olemassa oleva liittyvä palvelupyyntö päivitetään.
• Moderni toimintatapa: Jos sähköpostiviestin lähettäjällä ei ole sallittuja oikeuksia, työnkulkua ei käynnistetä.

Pariteettiaukot työnkulkujen ja Power Automaten työnkulkujen välillä (koskee vain sääntökohteen toimintojen mukautusta)

• Ensimmäinen ei tyhjäarvo -lausekkeita ei voi siirtää automaattisesti. Mukautuksen voi kuitenkin ottaa työnkulussa käyttöön manuaalisesti siirtoa varten.
• Valintatietueen näyttönimen yhdistämismääritystä merkkijonokentän kanssa ei voi siirtää automaattisesti. Mukautuksen voi kuitenkin ottaa työnkulussa käyttöön manuaalisesti siirtoa varten.
• Työnkulussa ei tueta aktiviteetin osapuolen kenttiä, joita käytetään lähdekenttinä.

Tunnetut työnkulkuongelmat

Siirretyillä säännöillä on ylimääräinen @-merkki kentille, joiden tyyppi on @ string

Jos vanha automaattinen tietueen luontisäännön työnkulku on mukautettu ja merkkijonokentässä on pelkän tekstin @-merkki, siirrossa näet kaksi @-merkkiä yhden sijaan. Jos esimerkiksi lisäät sähköpostiosoitteen tekstimuodossa palvelupyyntökuvauksen kenttään, @-merkkiä käsitellään erikoismerkkinä ja se siirretään @@-merkkinä.

Tämä johtuu siitä, että @-merkki tunnistetaan siirron työnkulussa erikoismerkkinä kaikille dynaamisille lausekkeille, kuten @triggerOutputs()?[body/_emailsender_value].

Voit kiertää ongelman poistamalla siirretystä työnkulusta manuaalisesti ylimääräisen @-merkin.

Siirto ei tue tilannetta, jossa samassa SLA:ssa on useita saman käyttöajankohdan omaavia kohteita tai ehtoja

WWW-asiakasohjelmassa SLA:n useisiin kohteisiin voidaan määrittää sama käyttöajankohta ja eri onnistumisehdot. Tätä ominaisuutta ei kuitenkaan tueta Unified Interfacessa. Tämän vuoksi siirron aikana ei luoda tämän tyyppisiä seuraavia SLA-kohteita, joilla on sama käyttöajankohtaehto.

Seuraavissa näyttökuvissa on skenaario, jota Unified Interface ei tue. Näkyvissä olevilla kahdella käyttöajankohtaehdolla on erilaiset onnistumisehdot.

Aktiviteettiosapuolen tyyppimääritteen ongelmat työnkulun muuntamisen työnkulussa

Toiseen aktiviteetin osapuolen tyypin kenttään määritettyä aktiviteetin osapuolen tyypin määritettä ei siirretä työnkulusta työnkulkuun -muunnoksessa, koska Power Automate ei tällä hetkellä tue kyseistä skenaariota. (Sähköpostiviestien useimmiten muuttuvat kentät ovat Vastaanottaja-, Lähettäjä-, Kopio- ja Piilokopio-kenttä.) Vaikka säännön siirto ei epäonnistu, tällaisen toisesta aktiviteetin osapuolen tyypistä riippuva aktiviteetin osapuolen tyypin kenttien tietoarvo on tyhjä siirron jälkeen.

Esimerkki: Aktiviteetin osapuolen tyypin määritteet

Siirtoa edeltävän WWW-asiakasohjelman näkymä

Selite:

a. Lähettäjä-kenttä on aktiviteetin osapuolen tyypin kenttä, jolle määritetään toinen aktiviteetin osapuolen tyypin määrite, {Bcc(Email)}. Se on tyhjä siirron jälkeen.

b. Vastaanottaja-kenttä siirretään.

Siirron jälkeinen Unified Interface -näkymä

Selite:

b.Vastaanottaja-kenttä.

Ensimmäinen ei tyhjäarvo -tarkistuksia ei tueta vanhojen työnkulkujen lausekkeissa työnkulusta työnkuluksi -muunnoksen aikana

Vanhoissa työnkuluissa valintakenttä voidaan yhdistää useisiin lausekkeisiin, joissa Ensimmäinen ei tyhjäarvo -lauseke valitaan ja määritetään alla olevan WWW-asiakasohjelman esimerkin mukaisesti. Tätä toimintatapaa ei tueta tällä hetkellä työnkulusta työnkuluksi -muunnoksen osana vanhan työnkulun suunnitteluohjelman tunnetun rajoituksen vuoksi. Tämän vuoksi työnkulun muunnin määrittää ensimmäisen lausekkeen ilman tyhjäarvotarkistusta. Tämän jälkeen se poistaa kaikki jäljellä olevat lausekkeet huolimatta siitä, onko niissä muita kuin tyhjäarvoja. Seuraavassa esimerkissä työnkulussa on tässä vaiheessa vain Regarding(Email) Asiakas-kentässä.

Esimerkki: Ensimmäinen ei tyhjäarvo -lausekkeet

Siirtoa edeltävä näkymä

Selite:

a.WWW-asiakasohjelman näkymä: Työnkulussa Asiakas-kentässä on {Regarding(Email); Contact(Create (Case)); Customer(Create (Case))}.

Unified Interfacessa Asiakas-kentässä on vain Regarding(Email) myös silloin, jos se on tyhjäarvo.

Tärkeää

Jos siirtotyökalun käyttämisessä on edelleen ongelmia, ota yhteyttä järjestelmänvalvojaan tai Microsoftin tukeen.

Katso myös

Modernin automaattisen tietueiden luonnin usein kysytyt kysymykset

Automaattisen tietueen luonnin sääntöjen ja SLA-kohteiden siirtäminen

Dynamics 365 -palvelutasosopimuksen ja ARC:n siirtymisen käsikirja