Skip to content
Insights

Product development

Role-based access that survives staff transfers

In institutions, people move every few years and the work stays. Permissions should follow the post, not the person.

WEKRAM Engineering · 25 September 2026 · 2 min read

Commercial software often assumes an employee joins, stays and leaves. Public institutions work differently: officers are transferred on a rolling basis, posts persist, and an incoming officer must inherit responsibilities without inheriting someone else’s password or a pile of stale permissions.

Model posts, not just people

Define the post (for example, a station in-charge) as a first-class object with permissions. People are assigned to posts for a period. When someone is transferred, the assignment ends and a new one begins. Nothing about the permissions needs to be re-created.

Preserve history

  • Records keep the identity of whoever acted at the time, even after reassignment.
  • Assignments have start and end dates, so ‘who held this post on that day?’ has an answer.
  • Deactivating a user never deletes their past actions.

Single-owner assignments need a handover

Where one person is accountable for one target, a transfer must not leave it orphaned. The system should prompt for reassignment and show unowned items, rather than letting them silently fall through.

Keep access honest over time

  • Periodic access reviews that list who can do what.
  • Least privilege by default; elevated rights are explicit and time-bound.
  • Every permission change is itself logged.
Written by the WEKRAM engineering team. These essays discuss general design principles and do not describe any specific client deployment.

Let’s build

Have a process that deserves better software?

Tell us what you’re trying to run. We’ll tell you honestly how we’d build it.