Some keys are handed over only after someone says yes. portierX tells from the spaces a key opens, and from the key itself, whether a yes is needed and whose. It asks those people by email and holds the copy back until every yes is in. The request is raised when an Organisation Admin, Access Manager or Credential Manager assigns such a key. Any role can decide, as long as portierX asks that person.
Also called: approval, sign-off, authorisation, four-eyes check. The screen says approval, and the person who decides is the Approver.
Two things set off a request. A key can set off both, and then each part is asked separately.
A key that opens a space with the protection need Very high needs a yes before it is handed over. The level can be set on the space itself or on its building or location, and the space takes it from there. Each such space is asked on its own. A key that opens three of them needs three yeses.
An example from the Nordwerk Industries demo. The Serverraum at Werk Nord has the protection need Very high. A copy of NW-GS-014 opens it, so assigning that key sends a request to the Serverraum's Approver.
An Organisation Admin can mark a mechanical master key, or a key above it in the master key system, as needing approval. Who may hold a marked master key is decided by the owner of its master key system. On this screen the master key system is called the locking system.
Every other key goes out without anyone else deciding. Whoever confirms the assignment commits it.
For a Very high space, portierX looks in this order and asks the first it finds.
The Approver named on the space, a person or a people group. In a group, any one member decides for the group.
If the space names nobody, the nearest Approver above it, on its building, then on its location. Approvers are named on spaces; an Approver named on a building or location answers for its spaces that name nobody.
If no Approver is named above either, the nearest Responsible above the space, on its building, then on its location, together with every Deputy of that place. Any one of them decides.
If nobody is named at all, the request waits. The space then shows on the dashboard under Places needing attention until an Organisation Admin names someone.
For a marked master key, the owner named on its locking system decides, a person or a people group. With no owner named, the request waits.
Whoever raised a request never decides it, and neither does the person the key is for. For a people group, no member decides. A person decides only with a portierX login that is linked to their own person record and active. Someone who has left, or whose login is paused or deactivated, is not asked and gets no email. Naming Approvers and owners is on Name approvers, owners and reviewers.
The request is raised on the Review assignment page, in the Business need section. That section appears only when a key needs a yes (Give a person access). What you enter there travels with the request to everyone who decides.
Field | Required | What it holds |
|---|---|---|
Requester | No | Who asked for the access, inside or outside the organisation, picked from People. Leave it empty when you are asking yourself. The Requester is told of the decision and the hand-over by email. |
Sponsor | No | Who in the organisation stands behind the access. Filled in with the person's manager; you can change or clear it. The Sponsor is a record only. portierX asks the Sponsor nothing and sends them nothing. |
Business need | Yes | What the job is, and why it needs this key. |
Basis | Yes | What the access rests on, such as a role, contract or work order. |
Qualification | Yes | Training or licence, and proof of it. |
Organisation | Yes | Company or department, filled in with the company on the person record. |
The start and end of the access are set on the same page.
One request covers one key. When three keys in an assignment need a yes, three requests go out. For a people group, one request per key holds every member's copy. One yes covers them all, and one no releases them all.
When the request is raised, portierX reserves the copy. The hand-over stays locked until every part of the request has its yes. Until then the key sits under People, on the Handovers tab, under Waiting for approval.
One no declines the whole request, and the reserved copy goes back in stock. After the last yes, the key can be handed over from its start date. Only the user who raised the request, or an Organisation Admin, hands it over. How a hand-over is confirmed is on Finish a hand-over that is still pending.
Goes to | When | |
|---|---|---|
"A key request needs your approval" | Everyone who can decide it | When the request is raised, and when it moves to someone named later |
"Still waiting for your approval" | Everyone who can decide it at that moment | Once, three days after the request was raised, if it is still waiting |
"Key request approved" | The user who raised the request | After the last yes, with a link to the person's page |
"Key request declined" | The user who raised the request | After a no, with the reason |
"Your key is ready to collect" | The person the key is for; for a people group, each member with a reserved copy | After the last yes, with the depot the copy is kept at and the start date |
"The key you asked for is approved" | The Requester | After the last yes |
"The key you asked for is declined" | The Requester | After a no, with the reason |
"The key you asked for has been handed over" | The Requester | When the key is handed over |
"Key handed over" | The user who raised the request | When the key is handed over, also when that user confirmed it |
The emails go out in the organisation's language. The reminder goes out after three days, unless the organisation has set another number of days. A cancelled request sends no email, and the Sponsor never receives one. Once the key is out, the people who said yes also receive its return reminders, see Return dates, reminders and overdue keys.
Approval follows the space. A key needs a yes because it opens a space whose protection need is Very high. A master key marked for approval is the second case.
Every Very high space and every marked master key needs its own yes. One no declines the whole request.
When nobody can decide, the request waits and the copy stays reserved. Once someone is named, the request goes to them, with an email.
Naming a different Approver or owner moves a waiting request only when nobody it asks can decide any more. A request a Responsible is answering moves to an Approver once one is named on the space or above it.
A yes does not let the Approver hand the key over. Only the user who raised the request, or an Organisation Admin, hands it over.
A copy reserved before its space was set to Very high, or before its key was marked, is refused at the hand-over too. Cancel that hand-over and assign the key again; the assignment then raises the request.
Access request statuses
Emails portierX sends
