I'm considering building a tablet-based visitor sign-in kiosk with Microsoft 365 instead of purchasing a dedicated visitor management system. The planned workflow would use Power Apps for visitors to enter their name, company, host, vehicle registration, and reason for visiting; accept a digital health and safety declaration; notify the host in Teams; store the log in SharePoint; show who is currently on-site; provide a one-click fire register; and support sign-out plus GDPR retention policies. For anyone who has built something similar, is this a sensible approach? What problems have you encountered with SharePoint or Power Automate? Would you choose Power Apps over Microsoft Forms, and what would you design differently in hindsight?
5 Answers
Before committing, test the fire register and retention rules under failure conditions. Decide what happens if Power Automate is delayed, the tablet is offline, a host account is disabled, or someone forgets to sign out. You may need a locally visible emergency list or a separate fallback process rather than assuming the live dashboard will always be available. Also document who can access visitor data, how long declarations are retained, and how records are securely removed.
Design the process around real visitors, not just the ideal case. Contractors may arrive several layers below the named host, may not know the correct employee or site contact, or may not appear on a pre-created list. Avoid making every visitor select an exact host before they can proceed; provide a reception or general-contact route and a clear escalation option. Otherwise the kiosk can create more work than it saves and send arrival alerts to the wrong people.
It can work, but compare the total cost of ownership with a dedicated service first. A visitor-management product may already include the kiosk experience, notifications, fire list, tablet support, updates, and compliance features for a fairly low annual cost. Building it yourself means owning the maintenance, testing, device management, and support when something breaks. We eventually replaced our custom Power Apps setup with a dedicated service because it was one less business system to maintain.
Power Apps is a better fit than Forms if you need sign-out, current on-site status, role-based views, and updates to an existing visit. Forms is simpler for collecting a one-time response but becomes awkward when you need a stateful workflow. Keep SharePoint as the data store rather than making it handle too much business logic, and plan for delayed flows, duplicate submissions, unavailable users, and a tablet losing connectivity. A kiosk-management tool can also lock the tablet to the app and prevent access to other settings or applications.
A custom build is feasible for a smaller site. One approach is to use a web app with a public visitor view and a restricted staff view protected by Microsoft Entra ID. Calendar appointments can be used to prepare visits, with the visitor completing the privacy and security acknowledgements on arrival. Store the completed record with an appropriate retention policy, and give reception or assistants a role that can view all scheduled visitors. I would avoid using an experimental or lightly tested build for anything critical without proper offline handling, audit logging, and failure testing.
That approach works particularly well when most visits are scheduled in advance, since the host only needs to confirm the visitor details. For unplanned arrivals, make sure reception can create an ad hoc visit without depending on a calendar entry.