Escalation: who may ask, and who may sign off

Who this is for: Owner — requires core.stepup.manage. Where: Settings → Escalation

This screen was called Step-Up Security and lived at its own top-level menu item. It is Escalation now, under Settings, because that is what the screen is actually about: not a security mechanism you configure, but an approval chain you write down.

It answers three questions per action — does this re-authenticate?, above what amount?, and, new here, who may ask for it and who may sign it off?

One row per protected action: the threshold, the switch, and the two halves of the chain.

Protected actions#

Each row is one action Nerve can protect — a folio refund, a folio adjustment, a POS discount, a POS void. The row carries its action key underneath the label, which is the identifier you will see in the audit and in API errors.

The switch decides whether the action re-authenticates at all. With it off, the action behaves normally for anybody whose role permits it.

Above is the amount threshold, in the property's currency. Leave it at 0.00 and every occurrence of the action escalates. Set it to a figure and only amounts over that figure do — which is how you protect the refund that matters without making the desk re-authenticate for a rounding correction. The field is disabled while the switch is off, because a threshold with no requirement is not a rule.

A row that has been changed from the built-in default carries a small badge naming where its current value came from.

Who may request, who may approve#

Under each action sit two panels: MAY REQUEST and MAY APPROVE.

Left alone, both read Anyone with the permission — the behaviour Nerve has always had, where holding the permission is the whole of the authorisation. That is a perfectly good answer for a small house, and you do not have to change it.

Naming somebody narrows it. To add an entry:

1. Select Add on the side you want — request or approve.
2. Choose a role or a person.
3. Choose whether it applies at one property or across the organisation.

Entries appear as chips reading the kind, the name and the property it covers. Remove one with the × on the chip.

Tip

Prefer a role to a person. A role survives someone leaving; a name does not. Reach for a named person when the authority genuinely belongs to that individual rather than to the job — an owner who signs off large refunds personally — and use a role for everything else.

Note

The person option only appears if you can read the team. Roles are readable in any active context, but people come from the team list, which needs org.members.invite. An administrator who can manage escalation but cannot read the team is offered roles only, rather than a picker that would fail.

What this changes, and what it does not#

This screen is administration, not enforcement. The step-up challenge itself — the moment a protected action stops and asks the person to re-verify — is unchanged and is described in the flow below. What changes is that the answer to “who signs this off?” stops living in a duty manager's memory and starts living somewhere a new manager can read it.

The verification record#

Below the actions, every completed verification is listed: when it happened, which action, the amount, the channel it was verified through, and the outcome.

This is a record, not a queue — nothing here is waiting for you. It is what you read after the fact, when a refund needs explaining.

How it connects#

• The roles and people you assign here come from Team and Roles.
• Every verification also lands in the audit log, alongside human, API-key and agent activity.
• Crossing into the partner portal is a different kind of re-authentication from escalating a refund — Realms explains the distinction.