# Requester portal

> The deliberately simple surface for occupants and residents - submit a problem, attach a photo, and watch its status. Nothing else.

Source: https://app.assetlab.ca/docs/cmms/requester-portal

The portal is what [Requesters](/docs/start/roles-and-access) see instead of the application: one place to report a problem and watch what happens to it. No asset registry, no queues, no training required.

## What a requester can do

- **Submit a request** - describe the problem, say where it is, attach photos from the phone camera
- **Track their own submissions** - status from received through converted to done
- **Edit a submitted request** - fix a typo or add the detail they forgot, from the tracking list
- **Talk to the technicians** - each request has a [live message thread](/docs/cmms/work-requests) with staff: answer clarifying questions, add details, see replies as they arrive
- **Manage their account** - a third portal tab holds their security settings
- **Nothing else** - they cannot see other people's requests, your assets, costs, or documents

That last line is the point: you can hand portal access to every teacher, tenant, or arena user group without any data-exposure conversation.

## Getting people into the portal

Invite them with the **Requester** role under **Settings → Users** (or via [self-registration options](/docs/manage/org-settings) if enabled for your organization). They sign in the same way staff do - email one-time passcode - and land in the portal automatically.

### The zero-login path: QR codes

Most reporters won't remember a URL. [Location and asset QR codes](/docs/asset-management/qr-codes) are the workaround: a scan on the broken door opens a submission form already tagged with that door. Post location codes at entrances, gyms, and rinks and problem reports start arriving pre-triaged.

## What staff control

Under **Settings → Requester Portal**, Administrators control six toggles:

- **Show work order status** - whether requesters see the status of the work order their request became
- **Show completion notes** - whether the close-out notes are visible to the requester
- **Allow location / asset / system / feature targets** - which "where is the problem?" pickers the submission form offers (the feature picker additionally requires the infrastructure module)

Auto-routing for incoming requests lives under **Settings → Work Orders** ([details](/docs/cmms/work-requests)).

## Communicating back

Each request's **conversation thread** is the channel: messages staff send appear in the portal live, new replies are emailed and badged as unread, and the same thread continues on the work order after conversion - so "any update on my door?" has a place to be asked and answered. Two habits pay off:

1. **Close the loop on declines.** "This is the landlord's responsibility - forwarded to them" costs ten seconds and preserves trust.
2. **Don't over-communicate mechanics.** Requesters see clean statuses and your messages - not your internal queue gymnastics. Internal coordination belongs on the [work order](/docs/cmms/work-orders) itself, which requesters never open.

## Related

- [Work requests](/docs/cmms/work-requests) - what happens after submission
- [Roles & access](/docs/start/roles-and-access) - how the Requester role is enforced