How Email-to-Request Works
One resident email in, one tracked thread out — no forwarding, no lost context.
5 min read
The problem: requests that live in someone’s personal inbox
Before a building has a tracked request system, resident issues almost always arrive by email — to whichever manager the resident happens to have a direct line to. That email gets forwarded, half-answered, and eventually forgotten in a thread nobody else can see. Email-to-request keeps the channel residents already use (email) while making sure nothing that arrives through it goes untracked.
Step 1: A resident emails the building’s address
Every building has its own dedicated inbound email address, visible to managers in building settings. When a recognized resident or owner emails that address, Pastrata creates a new request in the building’s inbox automatically — the email subject becomes the request title, the body becomes the first message, and any attachments come along with it. The request is attributed to the sender and marked as email-originated, but from that point on it behaves exactly like a request created in the app: managers can triage, assign, and respond to it the same way.
Step 2: The resident gets a confirmation, and can keep replying by email
The sender receives a confirmation that their request was received, with a link to view or respond to it. If they simply reply to that confirmation — or to any later update on the request — the reply is appended to the same thread instead of opening a duplicate. A reply to a request that had already been marked resolved reopens it, so a resident who says "actually, it’s still leaking" doesn’t have to start over.
Step 3: Unrecognized senders are held for a manager to review
A request is only created automatically when the sender is authenticated (so a spoofed "From" address can’t impersonate a resident) and resolves to an active member of that building. Mail that doesn’t meet both conditions — an unrecognized address, a former resident, a message that fails authentication — is held in a quarantine queue instead of silently creating a request. A manager reviewing the queue can convert a held message into a request (choosing the right building or member if needed) or discard it. Nothing enters the building’s record without either an automatic authenticated match or a manager’s deliberate action.
The other half: vendors reply by email too
The loop extends to vendors. When a manager assigns a work order to a vendor, or requests a quote, the vendor gets an email with the relevant details and a reply address tied to that specific thread. The vendor can reply — attachments included — without ever creating a Pastrata account, and that reply lands on the work-order thread exactly like an in-app update would, notifying the manager. A vendor’s email access is scoped strictly to the thread they were emailed about; replying never grants them broader access to the building.
Why this matters for managers
The net effect is one inbox instead of many: resident issues that used to scatter across personal inboxes become a single tracked queue a manager can claim and assign, and vendor conversations that used to happen entirely outside the platform — with no record anyone else could see — now live on the same thread as the work order they belong to. Nobody has to change how they communicate; the tracking happens underneath the email they were already going to send.
See it on your portfolio
A 30-minute walkthrough sized to your building count — and you leave with real portfolio pricing.