skip to content

A supervisor's acting-as session on an adjuster's queue has run for three days; what should entry, lifetime and exit have enforced?

level: seniorimportance: should knowfreq 35%

answer

  1. short absolute clock, not idle
  2. activity must not extend it
  3. an exit you cannot miss
  4. reason and approval at entry
  5. tell the person acted for

basics

~20 s

Entry should have required a recorded reason and an approval, the session should have carried a short absolute lifetime that activity cannot extend, and exit should be explicit, visible throughout, and shared with the expiry path so in-flight work lands the same way either way.

solid answer

~50 s

A three-day session means the clock was wrong and the exit was optional. Use a short **absolute** lifetime — minutes, not days — that requests do not renew, because a supervisor working steadily inside someone else's account is precisely the case you want bounded, and an idle timeout renews it forever. Make entry cost something: a typed reason and, for a cross-territory case, an approval recorded alongside it. Make exit unmissable: a persistent indicator naming whose account she is inside and a one-click way out, with the same code path the expiry uses, so unsaved work is handled identically whether she leaves or the clock does. Then tell the adjuster it happened. A notification gives the trail a reader with an incentive to look, which is the control that catches the misuse an internal review would not.

code

pseudocode · 17 lines
pseudocode
on_request(session):
    if session.subject != null and now() >= session.expiresAt:
        end_acting_as(session, ended_by = "expiry")
        return REDIRECT("/support?returned=expired")
    continue_handling(session)

on_exit_clicked(session):                      # same landing as the expiry above
    end_acting_as(session, ended_by = "supervisor")

function end_acting_as(session, ended_by):
    subject_id = session.subject.id
    session.subject = null                     # drop the borrowed half first
    release_locks(subject_id, session.actor)
    save_drafts_as(actor = session.actor, subject = subject_id)
    notify(subject_id, session.actor, session.reason,
           session.enteredAt, now(), ended_by)
    # the actor stays signed in under her own identity

go deeper

for a junior

Know that a support session borrowing another account is temporary: it has a clock, and there is a deliberate way out that the person must be able to see at all times.

for a middle

Explain why the clock is absolute rather than idle, and describe the entry record — who, whose account, why, and who approved it.

for a senior

Show the operational failures: the never-expiring busy session, the abandoned tab that ended nothing, and the half-finished work that must land the same way whether she exits or the clock does.

for a principal

Weigh how much support friction the organisation will actually tolerate, and decide who the notification goes to — the account holder, the customer, or both — before a regulator decides it for you.

## Why three days is the defect, not the symptom An acting-as session is safe because it is bounded and observed. A session that has been open for three days is neither: nobody knows whether the supervisor is still working, whether she remembers she is inside someone else's account, or whether the machine has simply been left unlocked. Every design property this feature rests on has quietly expired. Three things failed, at three different moments. ## Entry: a reason, and sometimes an approval Entry should not be a link that silently changes who you are. - **A typed reason**, stored with the session. "Claim file blocked, assigned adjuster on leave" is worth more than any automated signal, and knowing it will be stored changes behaviour on its own. - **An approval for the cases that deserve one.** Working inside another territory is the sanctioned exception to the desk's own boundary rule, so it is the natural place to require a second person. Ordinary same-territory support may not need it; crossing a boundary usually does. Record who approved, not just that someone did. - **Re-proof of the acting person's own identity** where the desk's risk appetite calls for it, so a walk-up at an unlocked machine cannot start one. ## Lifetime: absolute, short, and deaf to activity This is the part teams get wrong by reusing what they already have. An idle timeout is the right clock for an ordinary sign-in, where activity is evidence the right person is still there. It is the wrong clock here. | Clock | What it measures | Effect on a busy support session | |---|---|---| | Sliding idle timeout | How long since the last request | Renewed by every click; the busiest session never ends | | Long absolute lifetime | Time since entry | Ends eventually, but hours of borrowed authority is the exposure you were trying to avoid | | Short absolute lifetime | Time since entry | Ends on the same terms every time; long work re-enters with a fresh reason | Exposure grows with how long the borrowed authority is *available*, not with how quiet the session is. A short absolute clock — on the order of minutes — costs a supervisor on a genuinely long job one re-entry and one more line of reason, which is a fair price and a useful record. ## Exit: explicit, visible, and the same path as expiry Two failures are worth designing against specifically: she forgets, and she assumes. 1. **A persistent indicator** that names the account she is inside, on every screen, not a toast that fades. The point is that a glance answers "whose data am I looking at?". 2. **A one-click exit** from that indicator, returning her to her own identity without signing her out — the sooner the borrowed half is dropped, the smaller the window. 3. **One code path.** The expiry and the button should do the same thing: drop the subject, keep the actor signed in, and settle in-flight work identically. Two paths means the rarely-exercised one is the broken one. 4. **Closing the tab ends nothing.** The browser is not a participant in this decision; the session is server-side state and an abandoned tab produces no signal at all. Say this out loud in an interview, because the assumption that it does is extremely common. ## In-flight work at the moment of exit Whatever was half-done needs a defined landing. - **An unsubmitted form** is either discarded or saved as a draft attributed to the pair, never silently submitted later under the borrowed identity. - **Work handed to a background worker** must not complete under borrowed authority once the session is over. The safe default is that the session's own bound applies to it too; anything genuinely long-running belongs to the desk's own service identity rather than to a borrowing that has ended. - **An open editing lock** on a claim file is released, or the next person meets a record locked by someone who is no longer there. ## Notification: give the trail a reader The adjuster whose account was used should be told — who, when, for how long, and the stated reason — and, where the desk's policy requires it, so should the policyholder whose claim file was opened. This is the cheapest high-value control in the whole design, because it converts a trail nobody reads into one read by the person with the strongest incentive to notice something wrong. It also answers, honestly, the question a regulator or a customer eventually asks: "who looked at my file?" ## What the failure looks like later The expensive version of this is not a dramatic breach. It is a review eighteen months on that finds acting-as sessions averaging two days, no reasons worth reading, and no way to tell curiosity from work. At that point the trail exists but proves nothing, and the only remedy left is to bound the sessions — which is the thing that should have been true on day one.

  • Why an absolute lifetime rather than the idle timeout already used for ordinary sign-ins?
    An idle timeout measures the wrong thing here. A supervisor working steadily inside someone else's account renews it with every request, so the session you most want bounded is the one that never ends. Risk tracks how long the borrowed authority is available, not how quiet it is, so a short clock that runs regardless of activity is the honest bound — and re-entry costs one fresh reason.
  • Should the adjuster be told, given that the desk already keeps a trail?
    Yes, and it is cheap. A notification gives the trail a reader who cares: the person whose account was used will question a session they cannot explain, which is exactly the misuse an internal review sample misses. Where the desk's policy requires it, the policyholder whose file was opened is told too.
  • The supervisor closes her browser tab mid-session. What has actually ended?
    Only her view. The acting-as session is server-side state and a closed tab sends no signal, so the session stands until the explicit exit or the expiry fires. This is precisely why the absolute clock has to be short: it is the only thing that reliably ends an abandoned session.

saying these in an interview costs you the question

  • An idle timeout is fine for a support session too.
  • The supervisor will exit when she is finished.
  • Extend the session on activity so long work is not interrupted.
  • Closing the tab ends the acting-as session.
  • Nobody needs telling; the trail already records it.
  • Approval at entry means the lifetime can be generous.