Who Changed That Setting, and When
Locking down who can touch a setting stops the wrong person from changing it. It doesn't tell you who the right person was, or when they did it, once something's already different.
WiFi hours are set to close at 11pm, and one morning guests are locked out at 6am instead. Nobody at the front desk remembers changing it. Nobody meant to leave guests without internet before sunrise. The setting is wrong, it’s easy enough to fix, and the actual question left over, the one nobody can answer, is who changed it, and when. Was it a technician cleaning up something unrelated. A new hire who found the setting and guessed. A change made weeks ago that nobody noticed until now. Without an answer, the fix is the easy part. Making sure it doesn’t happen again, quietly, is the part that stays unsolved.
Permissions and history are two different problems
Staff roles solve a real problem: deciding, in advance, who’s even allowed to touch network settings versus who just needs to see who’s connected. That matters, and it’s worth getting right. But a role only answers “who’s allowed to do this.” It doesn’t answer “who actually did this, and when,” once a setting has already changed. Those are genuinely different questions, and getting the first one right doesn’t automatically answer the second. A technician role that’s correctly scoped to touch Open Hours settings is still a role several different technicians might hold over time, across several properties. Knowing the role was allowed to make the change tells you nothing about which specific person actually made it, or on which day.
Why “we lock it down” isn’t the whole fix
The instinct, once something changes unexpectedly, is to tighten access further: fewer people with the permission, a stricter role. That helps, but it doesn’t solve the actual problem, because the people who still need that access, the ones whose job genuinely is to manage network settings, can still make a change that turns out to be wrong, whether by mistake, by not realizing the effect on a different location, or because it made sense at the time and nobody wrote it down. Restricting who can act reduces how often something goes wrong. It does nothing for figuring out what happened after it already has. That second part needs a record, not a tighter lock.
What a real activity record actually needs
A useful answer to “who changed this” isn’t a vague sense that “someone from the team probably did it around then.” It’s a specific setting, a specific account, and a specific time, the kind of record that turns “I think it might have been changed a while back” into “Open Hours was changed on this account, on this date.” That distinction matters because the vague version isn’t actually useful for anything: it doesn’t help you have a real conversation with whoever made the change, it doesn’t tell you whether it was one mistake or a pattern, and it doesn’t give you anything concrete if the same thing happens again next month.
This is also exactly where each staff member having their own login, instead of one shared password everyone uses, stops being just a security habit and starts being the thing that makes any of this possible at all. A record of “the shared admin account changed this setting” tells you nothing, because that account could have been anyone with the password that week. A record tied to an individual login is the only version of this that actually answers the question being asked.
Where this matters most
The properties that feel this most are the ones where more than a couple of people ever touch network settings at all: a multi-location operator whose technician manages network settings across five properties, not just one; a property that brings in outside help, an installer or a vendor, temporarily; anywhere with real staff turnover at the front desk, where the person who set something up six months ago isn’t the person answering questions about it today. A single-owner cafe where one person manages everything rarely needs to ask “who did this,” because there’s only ever one answer. Past a certain number of hands on the dashboard, that question stops being rhetorical.
What to actually check
If you’re relying on account activity to answer these questions when they come up, a few things are worth confirming ahead of time, not after the fact. Is a change tied to the specific person who made it, or just to a shared account that could have been anyone. Does the record show the actual setting that changed, not just that “something in Network changed today.” Is it something you can pull up when you need it, or does it only exist as someone’s memory of what probably happened. And once someone leaves the team, does the record of what they changed while they were there stay intact, or does it disappear along with their account. None of this replaces getting roles right in the first place. It’s the other half of the same problem: roles decide who can touch a setting before anything happens; a real activity record is what tells you the truth about what did, after it already has.
