Role-based access
A finance colleague, site manager and contractor may use the same reception entrance but need very different rights beyond it. Their access should follow the job, not convenience.
Monday, 08:34. The main entrance.
The access log revealed an incorrect role assignment after an internal update
Illustrative reconstruction. The people, company and circumstances shown are fictitious
Read what happened

Why did security stop him at the entrance?
There was nothing unusual about his arrival. The managing director crossed the lobby with a takeaway coffee, pulled the same white badge from his wallet and held it to the reader. The little light turned red. The glass barrier did not move.
He tried again, a fraction more slowly this time. A colleague coming in behind him hesitated, then used the next lane. The director looked towards the security desk. “That worked yesterday,” he said. His badge had worked just the day before. He had not changed his routine, and there had been no reason to expect the gate to refuse him.
The officer knew his face, but still checked his identity and asked him to wait by reception. The card was active. It had not been cancelled. What had changed was his user profile: an internal update had accidentally assigned him a restricted access role, one that excluded the main entrance. An error in the system left him outside his office. Not a dismissal, not a row at the front desk — simply the wrong permissions attached to the right person.
Once the authorised access operator confirmed the mix-up, the team arranged a short-lived permission for that entrance. He could start his day while the permanent record was corrected. What might otherwise have turned into an argument had a much more useful ending: a precise explanation and a change that could be checked.
The answer came early: the badge was recognised, but an incorrect role denied entry through that door.
A familiar face still needs a valid access decision.
The reader refuses the badge at the main turnstile.
Security confirms the director’s identity and calls the authorised operator.
Time-limited permission gets the morning moving again.
The incorrect role is replaced and the temporary right removed.
The clue was already there
A valid card can still fail at a particular entrance. The first event showed the refusal; the account history showed the change behind it. Read together, the entries gave the access team something better than a hunch.
The temporary pass addressed the immediate problem without permanently broadening his access. It had a purpose, an authorised decision behind it and a clear end point.
Later, the access team returned to the record together. One unsuccessful tap now made sense next to the profile update that preceded it — and the correction that followed.
The director’s morning is a small example of a much wider challenge. An office may have several entrances, visiting contractors, changing shifts and people whose responsibilities change over time. Someone has to keep those permissions accurate — and be able to see what happened when an entry decision is questioned.
Paxton Net2 brings that work into an access-management system. Its software supports access levels, temporary rights and event histories, so authorised teams can manage entry rules and investigate unexpected refusals. Specific functions depend on the software edition and the installation.
Access levels connect a user with the doors and times appropriate to their role.
Temporary access can upgrade or restrict permissions for a defined period.
Live and historical events help operators look back at a decision made at a reader.
From one awkward morning
He did not need a new badge, a new door or an argument with security. He needed the right access role. The event record pointed the team towards it; a temporary permission kept things moving; and the permanent correction closed the loop. For any workplace managing a changing group of people, that is a useful question to ask of its access-control arrangements.