Work requests by email
Email intake - a dedicated address that turns incoming email into work requests, with no login required for the sender.
Email intake gives your organization a dedicated address like acme-staff-requests@requests.assetlab.ca. Anyone who emails it creates a work request - no account, no login, no app. It is built for the people who report problems but will never adopt a portal: field techs, tenants, contractors, the person who just noticed a leak. For them, filing a request is exactly as hard as sending an email - because that's all it is.
You can create as many addresses as you need - one per site, per team, or per audience - each with its own defaults and its own rules about who may use it.
How it works
When an email arrives at an intake address, AssetLab turns it into a work request in your organization:
| Becomes | |
|---|---|
| Subject line | Request title |
| Message body | Request description (plain text; formatting is stripped) |
| Sender | The requester on the request |
| Address defaults | Site, priority, and work category |
The sender is matched against your existing requesters by email address. A known sender's request is filed under their existing record, with their history; an unknown sender gets a new requester record created from the email. If that person later gets a portal account under the same email address, the record - and everything they ever filed - carries over to it.
The new request lands in Work Requests as Pending Review, exactly like a portal submission. From there your normal flow takes over: triage, conversations, approval or decline, and conversion to a work order. The sender immediately receives a confirmation email with the request title. When your team replies in the request conversation, each reply is also emailed to the sender - that is how you keep an email-only requester in the loop.
Setting it up
Administrators manage intake addresses under Settings → Email Intake:
- Create an address. Give it a name (e.g. "Staff requests"); AssetLab builds the address from your organization name and the name you chose. Because the address is easy to guess, use the sender policy below to control who can actually file requests - everything still arrives as Pending Review either way.
- Set defaults. Every request created from this address gets the default site, priority, and work category you choose. Categories feed auto-assignment, so a "Facilities requests" address with a default category routes to the right group automatically.
- Choose who can send:
| Policy | Behavior |
|---|---|
| Any sender | Anyone who knows the address can file a request |
| Known requesters only | Only senders already registered as requesters in your organization |
| Allowlist only | Only the specific email addresses you list |
- Share the address with the people who should use it, and tell them the one rule: subject = what's wrong, body = the details.
Each address has an on/off toggle - turning it off stops its intake instantly and is reversible. Deleting an address never touches the requests it created; if an address leaks to the wrong audience, delete it and create a new one under a different name.
Limits
- 30 requests per hour per address. Emails beyond that are dropped and the sender gets no confirmation - it protects your review queue if an address is spammed. A sender whose request didn't appear during a busy stretch can simply resend later. (The intake's internal message log is itself capped at 200 entries per hour, so a heavy flood beyond that leaves no per-message trace.)
- Forged senders are dropped silently. A message whose From domain fails DMARC - the sending domain's own "this is forged" signal - is discarded with no acknowledgement to the sender.
- Attachments are not imported. Photos or files on the email are ignored; your team can attach files to the request afterwards.
- Confirmation and conversation replies are the only automatic emails to the sender. Approving, declining, or completing the request does not notify them by itself - post a conversation reply when you want the sender to know the outcome.
- Replies don't thread back. If the sender replies to a confirmation or conversation email, that reply does not land in the request - and a new email to the intake address files a new request instead. For real two-way back-and-forth, give the person a portal account.
- Very long emails are trimmed to keep requests reviewable (titles at 200 characters, descriptions at 10,000).
Good practices
- Start with "Any sender" during rollout, then tighten to "Known requesters only" once your requester list is loaded - everything lands in Pending Review either way.
- Close the loop in the conversation. Email-only senders can't see the app - a one-line reply ("scheduled for Tuesday") is what tells them their email worked.
- Prefer the portal where you can. Email intake trades structure for convenience: no location picker, no photos on the initial request, no live status page. It's the on-ramp, not the destination.