Lähes kaikki ratkaisut pitävät sisällään jonkinlaista viestintää. Vähintään erilaisia ilmoituksia, joskus myös käyttäjien välistä viestintää.
Tämä pätee luonnollisesti myös Power Apps -rakaisuihin. Oikeita toteutustapoja on yhtä monta kuin on tarvettakin. Useimmiten viestintä on järkevintä hoitaa Teamsilla. Teams-viesteihin voi sisällyttää linkin, joka avaa oikean kohteen Power Appsissa (esim. työmääräyksen).
Joissain tilanteissa toimivin tapa on hyödyntää Power Appsin palveluilmoituksia (push notifications).
Keskitytään tällä kertaa seuraavanlaiseen tarpeeseen. Meillä on kentällä työntekijöitä (esim. asentajia). Asennustyömaat ovat isoja ja niiden sisältöön kohdistuu paljon muutoksia, joista asentajia tulee tiedottaa. Muutokset eivät kohdistu koko työmaahaan, vaan niiden sisällä oleviin osakokonaisuuksiin.
Haluammekin rakentaa Power Appsin sisälle yksisuuntaisen viestikanavan, jossa viestit kohdistuvat osakokonaisuuksiin. Lisäksi asentajien tulee nähdä helposti näihin osakokonaisuuksiin saapuneet uudet viestit.
Tietomalli
Aloitetaan tietomallista. Tarvitsemme seuraavat taulut.
- Asennustyömaa (Project, esim. kerrostalo x)
- Osakokonaisuus (Subproject, esim. asunnon y keittiö)
- Tehtävä (Subproject task, esim. keittiökaapistojen asennus)
- Viesti (Message). Viestillä on otsikko ja sisältö ja se liittyy aina johonkin osakokonaisuuteen (ja sitä kautta tietenkin johonkin työmaahaan).
- Luettu viesti (Read message). Taulu jossa ylläpidetään tietoa ketkä asentajista ovat tietyn viestin lukeneet. Joudumme teknisistä syistä lisäämään myös tiedon mihin osakokonaisuuteen viesti liittyy.
- Asentaja (User). Vakiotaulu käyttäjistä.
Luodut taulut näyttävät Dataverse for Teamsissa seuraavalta.
Testidatan lisääminen onnistuu suoraan käyttöliittymästä.
Asentajien mobiili Power Apps
Tehdään nopeasti mobiili-sovellus asentajien käyttöön. Alla näyttö, josta asentaja näkee yhteen osakokonaisuuden (esim. huoneiston X keittiö) liittyvät tehtävät tiloineen.
Hienoa! Nyt voimme ohjata asentajien työtä mobiilisovelluksen avulla. He näkevät suoraan kännykästä kohteen tekemättömät työt ja valmiusasteen eri tasoilla (koko työmaa, kerrokset, keittiöt jne jne).
He voivat kirjata työn ohessa lisätöitä. Voimme jopa pelillistää tekemistä hyödyntäen eri työvaiheiden laskennallisia kestoja ja vertaamalla niitä toteutuneisiin asennusaikoihin.
Unohdetaan kuitenkin kaikki tämä ja keskitytään niihin viesteihin.
Viestit
Kunkin asunnon huoneisiin tulee urakan aikana paljon muutoksia (tuleva asukas, urakan johto ja rakennuttaja tekevät kaikki muutoksia suunnitelmiin). Tarjoammekin asentajille näkymän työn alla olevaan huoneeseen liittyviin viesteihin.
Luodaan ensin muutama kyseiseen keittiöön liittyvä viesti.
Seuraavaksi luodaan näyttö, jossa esitetään yhteen osakokonaisuuteen (Subproject) liittyvät viestit. Eli galleria, johon suodatetaan viestit seuraavasti.
Items: Sort(Filter(Messages, Subproject.Subproject = varSelectedSubproject.Subproject), 'Created On', Descending)
Miksemme näytä valittuun aliprojektiin liittyviä viestejä? Eikös se ollut yksi Dataversen makeimmista jutuista?
Eli näin.
Items: Sort(varSelectedSubproject.Messages , 'Created On', Descending)
Kyseinen kaava aiheuttaa delegointiongelman. Miksi?
Koska haluamme järjestää viestejä. Dataverse ei (toistaiseksi) selviä siitä että järjestämme (tai suodatamme) käsiteltävään objektiin liittyviä rivejä. Tällöin on pakko mennä vanhalla tutulla tyylillä.
Lisätään lopuksi osakokonaisuusnäytölle kirjekuori-ikoni, josta käyttäjä siirtyy selaamaan viestejä.
Lukemattomat viestit
Mikäli viestejä viuhuu paljon, on käyttäjän nähtävä kunkin osakokonaisuuden kohdalla liittyykö siihen uusia viestejä.
Lisätään kirjekuori-ikonin päälle punainen ympyrä uusien viestien merkiksi. Ympyrän sisään vielä valkoinen otsikko, joka kertoo lukemattomien viestien määrän.
Lukemattomien viestien lukumäärä selviää helposti. Vähennetään osakokonaisuuteen liittyvien viestien kokonaismäärästä käyttäjän jo luetuiksi kuittaamansa viestit.
CountRows(
Filter(Messages,
Subproject.Subproject = varSelectedSubproject.Subproject
)
)
-
CountRows(
Filter('Read messages',
Subproject.Subproject= varSelectedSubproject.Subproject
And User.User = varCurrentDataverseUser.User
)
)
Huom: varCurrentDataverseUser on muuttuja johon olemme hakeneet sovelluksen kännistyessä (Office 365) käyttäjää vastaavaan käyttäjän Dataversestä.
Haluamme näyttää punaisen pallon vain jos käyttäjällä on lukemattomia viestejä. Eli pallon (ja lukumäärän) näkyvyys on seuraava.
Visible: lblUnreadMessages.Text <> "0"
Viestin kuittaaminen luetuksi
Jotta tiedämme mitkä viestit käyttäjä on jo lukenut, tulee käyttäjän merkitä viestit nähdyksi.
Lisätään tätä varten viestigalleriaan painike (Mark as read).
Nappia painettaessa lisätään rivi Read Messages -tauluun.
Patch('Read messages',
Defaults('Read messages'),
{
Name:"read by " & User().FullName,
Message:ThisItem,
User:varCurrentDataverseUser,
Subproject:varSelectedSubproject
}
)
Viestilistalla painike näytetään ainoastaan, mikäli käyttäjä ei ole kuitannut viestiä luetuksi.
Visible: IsBlank(
LookUp('Read messages',
Message.'Message (crb24_messageid)' =
ThisItem.'Message (crb24_messageid)',
User.User = varCurrentDataverseUser.User
)
)
Painikkeen näkyvyyden perusteella meidän on helppo muotoilla viestejä. Esimerkiksi lukemattomien viestien otsikko esitetään lihavoituna.
FontWeight: If(btnMarkAsRead.Visible, Bold, Semibold)
Yhteenveto
Näin olemme toteuttaneet yksisuuntaisen viestinnän työnjohdolta asentajille. Monessa tilanteessa oikein hyödyllinen ominaisuus.
Läpikäydyssä toteutuksessa on muutama optimointia vaativa kohta, mutta tunnistat ne todennäköisesti jo itsekin.
Ole kuitenkin tarkkana tämäntapaisten viestiratkaisujen kanssa. Niistä on yllättävän lyhyt matka siihen, että olet rakentamassa asentajille omaa Facebookia. Ja siinä ei sitten ole mitään järkeä.
Useimmiten oikea työkaluyhdistelmä on Teams (viestintään) ja Power Apps (tekemiseen). Äläkä unohda niitä Power Appsin palveluilmoituksia.
Timo Pertilä 