Use case

Contractors

Each contractor has a sponsor and an end date. When the work ends, cards stop and keys come back.

A contractor has a sponsor and an end date. When the work ends, the card is blocked and the sponsor answers for the key, brings it back, and once it is returned all access is removed.

The problem

Contractors get keys and cards to do a job.

The job ends, and the access often stays.

Nobody inside owns a contractor’s access, so nobody notices when it should have ended.

What portierX does

Each contractor is a person in portierX, with their company, a sponsor and an end date.
portierX: a contractor's record with company, manager and end date (invented demo data)
Keys and cards are issued against that record, each with a due date.
portierX: a key handed over in person and signed for on screen (invented demo data)
When the work ends, cards are blocked in the connected systems and keys are followed up until they are back.
portierX: a SALTO card blocked from the person's record (invented demo data)
The sponsor answers for anything still out.
Every issue, return and approval is on record.
portierX: a history of keys issued and returned, ready to export (invented demo data)

Industries

Where the use case comes up most

Utilities and critical infrastructure

Remote sites, long-lived assets, and a record of who held which key and when it came back.

Real estate and multi-site organisations

One way of working across every building, site and manufacturer.

Healthcare and hospitals

Access stays correct through shift changes and contractor rotations.

Common questions about contractors

Can a contractor’s access end on a set date?

Yes. Each contractor has an end date. When it passes, the keys and cards show as due, and one step blocks the cards in SALTO and dormakaba MATRIX.

Who answers for a contractor’s keys?

The sponsor named on the contractor’s record.

Further reading

Insights related to this use case