Genvägar ämne och tips

Denna sida med genvägar till olika ämnen är till för dig som är van systemet men som söker en specifikt ämne eller vad som nyligen förändrats i systemet. Till skillnad från våra FAQ sidor som innehåller så gott som alla frågor vi fått så innehåller denna sida ämnen som ni kanske inte visste att ni kunde förbättra ert arbete med och därför inte frågat. Här finns även tips på hur man skall lägga upp organisationen och hur man hanterar specifika situation. I texten nedan använder vi bara ordet "kort" men det kan också vara en tag eller smartwatch etc.

    Ämnen

      Tips

        Uppdateringen av appen Criotive access 2021-02-11 påverkar nedanstående ämnen.

        Uppdateringen 2020-02-20 påverkar nedanstående ämnen.

        Byta nyckel från ett kort till ett annat.

        Att tänka på: När en användare installerar en nyckel på ett kort registreras kortets serienummer på användaren i systemet och samma kort kan inte användas igen av någon annan i samma Merlify organisation även om kortet raderas i appen. Detta är troligtvis en akademisk fråga då man byter kort för att det första är förbrukat av en eller annan anledning.

        Förfarande: Detta kan endast hanteras i appen Criotive access, inte i Criotive Kiosk.
        Bakgrund: Användaren skall förnya sitt Legitimationskort där även den elektroniska nyckeln är installerad.
        1 - Användaren öppnar appen Criotive access loggar in och ta bort nyckeln på befintligt kort/bricka: Ta bort nyckel.
        2 - Admin publicerar aktuell nyckel igen.
        3 - Användaren accepterar och installerar nyckeln på ditt nya kort/tag

        Användaren har glömt sitt kort.

        Att tänka på: Det finns ingen 100% lösning för detta. När en användare installerar en nyckel på ett kort registreras kortets serienummer på användaren i systemet och samma kort kan inte användas igen av någon annan i samma Merlify/Criotive organisation även om kortet raderas i appen. Det innebär att när ni gjort en tillfällig reservnyckel till användaren och sen raderar den när användaren åter börjar använda sitt orginalkort så kan inte reservkortet användas av någon annan i organisationen trots att den är raderad då kortets serienummer har låsts till första användaren. När den är raderad är den dock ofarlig ur en access-synpunkt.

        Bakgrund: I begreppet "glömt" räknar vi med att användaren kommer att återfå sitt orginalkort och använda detta framöver.
        1 - Admin/utgivare använder/skapar en nyckel med identisk regel och låsgrupp som användarens orginalnyckel men lägger endast till den unika användaren och publicerar nyckeln.
        2 - Användaren tar ett tillfälligt kort, accepterar i appen och lägger nyckeln på det tillfälliga kortet.

        Vilken policy skall vi ha när vi döper nycklar och användargrupper?

        Det är frestande att döpa en användargrupp med användare som jobbar i byggnad A för "Byggnad A" och en Nyckel som ger access till alla lås i byggnad A för "Byggnad A". Även om användargrupper och nycklar har olika platser i adminverktyget så är det lätt för dem som inte arbetar så ofta i systemet att då bli förvirrade. Vårt förslag är att man döper dem till "Användargrupp Byggnad A" respektive "Nyckel Byggnad A" för att tydliggöra vad det är.
        Ibland behöver man göra kombinerade användargrupper och nycklar för dem som jobbar i två, tre och fler byggnader. Ta då för vana att döpa dem i bokstavsordning och låt det vara kännt bland era administratörer/utgivare.
        En kombinerad nyckel för Byggnad B + Byggnad C + Byggnad A bör heta "Nyckel Byggnad A+B+C". Det är annars lätt hänt att det läggs upp fler nycklar som har samma funktion men heter olika. Exempel: "Nyckel Byggnad A+B+C" har samma funktion som "Nyckel Byggnad B+C+A"

        Varför skall vi använda användargrupper?

        Användargrupper är ett sätt att samla alla som skall ha samma nyckel och i ett steg koppla hela gruppen till nyckeln. Man kan tycka att det är minst lika tidsödande att lägga in alla enskilda användare i en användaregrupp plus att sedan koppla den gruppen till nyckeln som att lägga in användarna direkt på nyckeln. Så långt är det sant. Men vid en framtida förändringar så har man igen att man var strukturerad från början.
        Exempel: Ni har idag 100 användare i byggnad A och 100 användare i Byggnad B som alla får en gemensam "Nyckel byggnad A+B" . Imorgon tas beslutet att dessa byggnader skall separeras accessmässigt och två nya nyckalar skapas "Nyckel Byggnad A" och "Nyckel Byggnad B".
        Det blir då lätt att lägga respektive användargrupp på respektive nyckel.
        Det ger även andra fördelar, när man tittar på hur en nyckel är uppbyggd så blir det tydligt vilka grupper som får nyckeln där det för den oinvigde kan vara svårt att se sambandet om det bara är många användare listade på nyckeln.
        Exempel: Nyckel Byggnad A skall ges till "Personal Byggnad A", "Sjuksköterskor" och "Chefer". För den som anställer en sjuksköterska är det sen lätt att lägga densamma i gruppen "sjuksköterskor" utan att för den skull ha kännedom om hur administratören tänkt när det gäller organisationens accesspolicy. Fördelarna blir ännu tydligare med vår kommande funktion "sammanslagna nycklar".

        Tänka brett eller smalt när ni ger ut access?

        Vad är för respektive nackdelar med att hålla accessen smalt respektive ge ut lite för mycket access? Ni har användare som jobbar på avdelning A men kanske även på avdelning B och C någon gång i semestertider när ni behöver rotera scheman. Hur skall ni tänka då?
        Om ni ger ut access för bara avdelning A:
        Effekt 1: Begränsad access för användaren ger nackdelen att ni behöver ge ut en ny nyckel de gånger de behöver förändrad access till olägenhet för admin och användare.
        Effekt 2: Ni har riskminimerat men skall ändå ta i beaktning att användaren loggas på alla ställen så hur stor är risken i slutänden?
        Effekt 3: Användaren kan känna en trygghet i att "sker oegentligheter på avdelning B blir inte jag misstänkt för jag har inte access dit"
        Effekt 4: Om användaren förlorar kortet så kommer "kopian som ersätter orginalet" att behöva presenteras för alla lås där användaren har access för att den förlorade kortet skall bli obrukbart. Det kan bli betydligt färre lås att gå runt till än om ni gett ut access i överkant. Det kan finnas en tidsaspekt också på att det kan ta tid att hinna runt till alla lås. Se avsnittet: Förlorat kort.
        Om ni ger ut access till avdelning A, B och C blir ovanstående effekter det motsatta.

        Hur kan jag verifiera att rätt kort används vid uppdatering?

        I systemet på respektive användare har ni en flik "Enheter" som berättar på vilket eller vilka kort/tag/telefon som en nyckel är installerad. På respektive enhet står ett ID nummer. Detta ID kan läsas av från ett kort/tag med en app som heter NFC Taginfo by NXP. Gör så här:

        Ladda ner appen NFC Taginfo by NXP på en Android. Den finns även för Iphone men förutsätter att man aktiverat NFC med ett kreditkort…

        När appen är aktiverad så lägger man telefon mot kort/tag och trycker på fliken ”Full scan” se  i samma flik efter ”Detailed protocol information” och ID: xx:xx:xx:xx

        Se bifogad bild och jämför numret med informationen i Criotive

        Image
        Image

        Hur ni bygger en nyckel!

        Bygg nyckeln i små beståndsdelar för en stor flexibilitet. Vi ger ett exempel med en organisation som har anläggningar i 4 städer som ligger i två län och ett land. Minsta enhet för access är en anläggning i en stad. Bygg dina grupper på de minsta beståndsdelarna och koppla så många som behövs för att skapa den nyckel du vill åstadkomma. Det innebär för access till "alla i skåne" skall du inte skapa en grupp som är "skåne" utan lägga till accessgrupperna Malmö och Lund på nyckeln. Samma gäller för användargrupper. Om du skapar användargruppen Skåne, Malmö och Lund kan förvirringen bli stor var "Per Persson" skall ligga som både är Skåning och Malmöbo. Du som skapade detta kanske kommer ihåg lite specialare men om en kollega skall arbeta parallellt eller ta över så blir det jobbigt. Desutom kanske regionen förändras och någon skall ha tillgång till Lund och Mjölby separat. Den nyckeln skapas lika enkelt som "Nyckel Skåne".

        Nyckeln fungerar inte efter uppdatering

        Vi har upptäckt att vissa nycklar inte fungerar efter att det har blivit uppdaterade enligt "automatisk uppdatering". Ibland finns det en naturlig anledning att användaren inte bara uppdaterat en nyckel utan två, och den senast skrev över den första, men om det inte är fallet: Pröva först att lösa problemet enligt nedan
        1, Användaren skall radera nyckeln från kort/tag i appen.
        2, Publicera nyckeln igen i admin.gränssnittet
        3, Användaren installerar nyckeln på kort/tag i appen
        Detta bör lösa problemet.

        Det är inte alltid problemet löser sig med ovanstående. Ni kan göra nedanstående som alltid löser problemet men får andra konsekvenser. Konsekvensen blir att alla som har nyckeln kommer få ett meddelande om att uppdatera sin nyckel och med det får alla förändringen. Här får ni avväga nyttan mot olägenheten.

        1, Förändra regeln på nyckeln. Exempelvis sluttid från 07.30 till 07.31 så blir förändringen inte så dramatiskt
        2, Publicera nyckeln igen i admin.gränssnittet

        Om ni kommer fram till att ni inte vill förändra giltigheten med dess konsekvenser återstår att skapa en ny nyckel som ni skickar till de användare med problem. Glöm inte att ta bort dem från urspungsnyckeln så att de laddar på båda....

        Vi jobbar på att lösa problemet men visar sig inte vara så enkelt då det hänger ihop med förändringar i Google/Android.