Kindoo Access Control System

[rknelson]

...my point is that if a stake is "aggressively" using the sync-and-manually-remove process to both automate things, as well as to try and minimize unused licenses, they need to also be aware that the licenses they manually free up may not always be that way.

I view the automatic sync as a way to deal with the 80% of callings that obviously need access and where there aren't multiple people with the same calling in a unit. We don't automatically add assistants, organization secretaries and many other callings - there are certainly cases where they need access, but manually adding them makes more sense. FYI, we've been on Kindoo for a year now. Just over 13% of current invitees have never accepted their invitation (most of them are a year old invite and re-invites were sent several times) and I haven't trimmed them out in bulk because we have enough licenses. We can trim those back when needed and we could go further (more work by parsing the logfiles) to reclaim licenses from users that never (or very rarely) use them. I send the ward Executive Secretary and Clerk with CC to Bishop a list of current users periodically which also includes if the invitation was accepted. They trim out unaccepted invites sometimes. They know the number of licenses allocated to their unit and I always tell them we have a few extra licenses if needed. In my experience the overreaction on the number of users (which I also had initially!) calms down and really isn't an issue over time. If after a few months you feel there is an issue (we haven't) work with the Stake President to request FM to add more licenses.

[ELHawkes]

What happens in regard to licenses when a member has two callings that are Auto synchronized? For example what if the callings of high counselor and Stake Building rep are both synchronized and the same person has both callings.

[rknelson]

What happens in regard to licenses when a member has two callings that are Auto synchronized?

Kindoo only issues one license for each unique email address. Trying to add a second user to an existing email generates a "Duplicate Entry" error. High Councilors often have double callings like Stake Young Men President, Stake Sunday School President, and Stake Building Representative.

[sbradshaw]

I also would like to note my disappointment in the fact that we are going away from FOBs.

FOBs have many of the same problems as keys. They have to be tracked. They can also be swiped or loaned out inappropriately. During one of the safety briefings we've had, we were told about the wayward child of a released church leader who got their hands on dad's keys and trashed the meetinghouse. Dad still had the keys because no one wanted to take the keys back from the released leader. With the Kindoo system, the son would have to take the phone. And once released, a leader's access is revoked automatically. Given the ongoing cost of Kindoo, I'm sure the leaders weighed the options, but valued the security and linking to one's calling other more common methods.

It may be a step back in user convivence, but a step up in security.

FOBs that rely on simple RFID or NFC can also be easily duplicated/cloned to other devices. The Kindoo app connects to the internet to authenticate with a rotating code that changes frequently, making it much harder to clone (if I'm understanding the technology correctly). Having access tied to Church Accounts also provides a clear audit trail, if there's a need to see who accessed the building at a given time or day.

[waymana]

Question regarding manual removal of members in synced callings, when they are eventually released. As an example, let's say the stake decides all Organists should be automatically synced (I'm not saying it makes sense, just using it for example). And then 6 of the 10 organists in the stake say they don't need access, and so their 6 user licenses are then returned to the general pool. When one of those organists is eventually released and a new one is called, I believe the automatic process will then assign that organist as a Kindoo user, correct? And of course that new organist may or may not want to retain building access.

I think it is more difficult to remove access from some members vs assigning them manually upon request. It is also less confusing for members who would receive an email from Kindoo and then not have access. I would recommend that the Stake President identify callings that can receive Kindoo access if requested and it is communicated out to the Bishoprics. Organists have a legitimate need to have building access so that they can practice the organ as they likely don't have one at their home. However, if an organist/accompanist doesn't need access then that frees up a license.

[mdigi]

Interesting, I've never seen a Kindoo system. I wonder if my stake will be implementing that technology anytime in the near future?

I'm surprised by the key licensing limitations. I would think the church would prefer to negotiate an unlimited key license for all units to use? Or, if Kindoo doesn't provide a cost effective way to do that, the Church could just build their own access control system. I've done that before and it's pretty easy. The door actuators/strike plates and UPS (one per site) are the biggest expense -- but Kindoo likely has those same requirements.

My biggest worry with using my phone as the key to my home/garage is I have tendency to drain my phone battery nearly dead at the end of the day
I'd have the same worry with an electronic [phone based] church key or having my temple recommend solely on my phone.

[BrianEdwards]

For all those with (understandable) concerns about the Kindoo system, I'd also add that it is currently being successfully used in very high-traffic situations that I'm aware of. One building is the Kirtland Stake Center, which from my limited experience seems to be constantly in use (especially over the spring/summer/fall) by large groups that are visiting Kirtland, in addition to the normal local usage. Another is the stake center which sits on the same lot as our local Temple, and the stake center gets a similar traffic pattern of out-of-stake groups that desire to use the building as a gathering place for different activities (many members travel multiple hours to get to our Temple, so it can be an all-day affair). I know this stake center has many additional building needs like Pathways groups, YSA gatherings, ARP meetings, etc, that they also balance. These two buildings have had Kindoo for a few years now, and I've used the Kindoo app a couple of different times for each of those buildings, and from my end-user perspective things worked nicely.

Interestingly, the first time I was a bit perplexed as to why the Kindoo admin didn't want to give me access until two days before our event. I kept getting worried that our group would be forgotten, so I ended up bothering the admin multiple times that week with the same request (please don't forget us). Now I understand it was due to the fact that once a reservation is made in the system, I would take up a license until our event finished, and they probably had mid-week people who also needed temp licenses. Perhaps this was communicated to me somewhere in the various emails, but I may have missed it. I can't speak as to how easy it is for the Kindoo admins for each of these buildings to manage things, but I'm guessing it's a constant churn, and they may have an additional resource/manager to help spread the load.

[martelldansie]

I also would like to note my disappointment in the fact that we are going away from FOBs. I use FOBs for my Gym and Community Theater access and they all can be programmed to the same FOB for ease of use. But I don't want to have to use an app for this system only - it feels like we are going backwards in the use and implementation of technology. I am sure for those who didn't adopt the FOBs well they probably won't know the difference but for us we will have extreme challenges going forward. And we do have many who don't have smart phones.

FOBs have many of the same problems as keys. They have to be tracked. They can also be swiped or loaned out inappropriately. During one of the safety briefings we've had, we were told about the wayward child of a released church leader who got their hands on dad's keys and trashed the meetinghouse. Dad still had the keys because no one wanted to take the keys back from the released leader. With the Kindoo system, the son would have to take the phone. And once released, a leader's access is revoked automatically. Given the ongoing cost of Kindoo, I'm sure the leaders weighed the options, but valued the security and linking to one's calling other more common methods.

It may be a step back in user convivence, but a step up in security.

This logic doesn't make sense to me. FOBs can be turned on and off remotely when callings change. Yes they can be shared with counselors and others needing access for a one time event but now you will inconvenience all leaders in requiring that they go for those one-time events.

[russellhltn]

FOBs can be turned on and off remotely when callings change.

FOBs can be turned off - but will they? How hard would it be to link it to callings? Kindoo seems to offer an API to do it.

Yes they can be shared with counselors and others needing access for a one time event but now you will inconvenience all leaders in requiring that they go for those one-time events.

First, there's no need to arrange to meet for a hand-off for keys or fobs (and trying to get them back). From what I'm reading here, there's ways of assigning a license for a one-time event. When done, you get that license back. No run-around trying to make it happen.

[russellhltn]

I'm surprised by the key licensing limitations. I would think the church would prefer to negotiate an unlimited key license for all units to use?

If there's no pressure to limit the number of licenses, then why not just give everyone access? Far less work to manage that way.

I think there's wisdom of keeping wards/stakes just a little "hungry" so they manage their license to those who who have an actual need for it.