Project Mailbox: How Inbound Email Becomes a Task in Onplana

Here is a test. Count how many times this week you converted an email into a task manually. A vendor replied to your status update with a change request buried in paragraph three. You copied the relevant sentence, opened the PM tool, created a task, pasted in the text, set an assignee, and went back to email. That sequence took about two minutes. If it happened five times this week, you spent ten minutes on a process that should be automatic. A project mailbox eliminates this step.

Most PM teams live at the boundary between email and tasks. Stakeholders communicate by email because it is the coordination medium they are comfortable with. Project teams manage work in a PM tool because that is where tasks, timelines, and accountability live. The bridge between those two systems is usually manual: read the email, interpret whether it requires action, open the PM tool, create the item, fill in the details.

A project mailbox closes that gap. Each project in Onplana has an email address. Messages sent to that address are parsed and converted into tasks or comments on the project automatically. The sender does not need an Onplana account. The PM team does not need to watch an inbox for items to transfer. The email becomes part of the project record the moment it arrives.

TL;DR. Onplana's project mailbox assigns a unique inbound email address to each project. Emails sent to that address become tasks or comments automatically, with the subject as the task title, the body as the description, attachments preserved, and the sender's address recorded as the reporter. Routing rules control whether each email creates a new task, adds a comment to an existing task, or goes to a triage queue. Sender authentication via SPF and DKIM, plus optional domain allowlists, prevents unauthorized input.

What Is a Project Mailbox?

A project mailbox is an email address that belongs to a specific project in Onplana. The address takes the form project-slug@mail.onplana.com, or a custom domain if your organization has configured one. Anything delivered to that address is processed as an inbound action on the project.

The concept exists in help desk and customer support systems under names like "ticket email" or "support inbox." What Onplana's project mailbox adds is the PM context: routing rules that connect inbound emails to the right project artifact (task vs. comment), attribution to the project's team structure, and integration with Onplana's task model including priority, assignee, due date inference, and attachment handling.

For people outside the project team, including vendors, clients, and system integrations, the project mailbox is just an email address. They send to it as they would any email address. What happens on the other side is invisible to them: the email becomes a structured task in the project, routed to the right person, with their original message preserved and accessible.

How Project Mailbox Works in Onplana

When an email arrives at a project mailbox address, Onplana processes it through standard SMTP delivery (RFC 5321) and applies a parsing and routing pipeline.

The diagram below shows the flow from email arrival to task creation.

Parsing. Onplana extracts the subject line as the candidate task title, the body text (plain text or HTML-stripped) as the description, the sender's email address and name as the reporter, the timestamp, and any file attachments. Attachments are stored in the project's file storage and linked to the task or comment.

Authentication. Onplana validates SPF and DKIM headers on every inbound message. Messages that fail authentication are quarantined rather than processed. For projects configured with a domain allowlist, messages from senders outside the approved domains are quarantined even if they pass DKIM validation. This prevents unauthorized input from reaching your project record.

Routing. The routing engine checks the parsed message against the project's routing rules. If a rule matches, the engine applies the configured action: create a new task, add a comment to an existing task matched by a subject keyword, or route to a triage queue. If no rule matches, the default action applies, which is configurable per project.

Attribution. The task or comment records the sender's email address as the reporter. If the sender's email address matches an Onplana user account, the attribution links to that user's profile. If not, the sender appears as an external reporter with their email address displayed.

Three Primary Use Cases for Project Mailbox

Vendor coordination. Vendors, contractors, and professional services firms communicate primarily by email. When a subcontractor sends a change request, a delivery confirmation, or a status update to the project mailbox address instead of to the PM's personal inbox, it enters the project record immediately. No forwarding, no copy-paste, no manual task creation. The PM reviews the created task, adds context, assigns it, and the communication is part of the project timeline.

Client request intake. For teams that deliver projects to external clients, the project mailbox address serves as the client's point of contact for requests. The client sends feedback, questions, or new requirements to the address. Each email becomes a task in the triage queue. The PM reviews it, decides whether it is in scope, and either converts it to an active task or closes it with a documented reason. The entire intake process is visible in the project record, not distributed across team members' personal inboxes.

Automated system alerts. Monitoring tools, CI/CD pipelines, and operational systems can send alerts by email. A staging environment failure, a build error, or a deployment notification sent to the project mailbox becomes a task automatically. The routing rules can assign these to the relevant technical team member based on keyword patterns in the subject line, so the engineering PM does not need to act as an intermediary between the monitoring system and the person who needs to respond.

Routing Rules: Getting Each Email to the Right Place

Routing rules are conditions applied to inbound messages that determine what Onplana does with them. Each rule has a condition (subject contains, sender domain is, sender email is) and an action (create task, add comment, add to triage, discard).

Rules are evaluated in priority order. The first rule that matches an inbound message determines the action. If no rule matches, the project's default action applies.

Common rule patterns:

• Subject keyword to task. Messages where the subject contains "change request" or "CR:" create a task with the label "Change Request" and assign it to the project's change manager.
• Sender domain to comment. Messages from @client-company.com add a comment to the task whose subject line most closely matches the email subject. This works well when clients reply to existing task threads by email.
• Sender address to triage. Messages from an address not on the approved sender list go to the triage queue rather than creating tasks automatically.
• Subject keyword to discard. Out-of-office replies and email delivery notifications often have predictable subject patterns. A rule can discard these automatically to prevent them from creating tasks.

Routing rules can also set task attributes: priority level, assignee, label, and due date inference. If your CI/CD pipeline's failure alerts always require same-day response, a routing rule can set the priority to Urgent and assign to the on-call engineer automatically.

The Security Model Behind Project Mailbox

The project mailbox address is not secret. In many cases, you will share it openly with vendors or clients. The security model does not rely on secrecy; it relies on authentication and authorization controls.

Sender authentication. SPF validation confirms that the sending mail server is authorized to send on behalf of the sender's domain. DKIM validation confirms that the message content was not altered in transit. Messages that fail either check are quarantined. The quarantine queue is visible to project admins for manual review and release.

Domain allowlisting. For projects where only a defined set of external organizations should be able to create tasks, you configure a list of approved sender domains. Only messages from those domains pass through to routing. All others go to quarantine regardless of authentication status. This is the right configuration for client intake projects where you want a specific client's team to submit requests but not the general public.

Assignee permissions. Tasks created by inbound email follow the same permission model as tasks created within Onplana. The reporter (sender) has no permissions in the project. They cannot view the project, see other tasks, or take any action beyond sending email to the mailbox address. All project visibility and editing permissions are governed by the Onplana project role assignments, not by email access. For detailed context on how Onplana handles authentication and access control, see the security and compliance overview.

What Project Mailbox Does Not Replace

Project mailbox is a specific tool for a specific problem: converting inbound emails from external parties into structured project items without manual intervention. It is not a general-purpose email integration.

It does not replace team communication. Project mailbox is for external input: vendor messages, client requests, system alerts. Internal team communication, including task discussions, status updates, and coordination, belongs in Onplana's native commenting and notification system, not in email-to-task conversion. The discipline of keeping internal work in the project tool, not in personal inboxes, is what makes project mailbox useful: if PMs are still conducting substantive project conversations by personal email, the mailbox does not fix that.

It does not replace status reporting. A vendor sending a progress update to the project mailbox creates a task, not a status report. That task still needs to be reviewed and integrated into the project's actual status by the PM. The status report writing guide covers how to structure status communications so that input from multiple sources, including inbound email, translates into a coherent project status rather than a list of unrelated tasks.

It does not handle bidirectional email threading automatically. If a vendor replies to a project notification email expecting a conversation, the reply creates a new task or comment. Onplana does not yet send replies from the project mailbox address, so the conversation thread in email diverges from the task thread in Onplana. Teams that rely on email threading with external parties should set expectations about which channel is authoritative for a given exchange.

Setting Up Your First Project Mailbox

Setting up a project mailbox takes five steps and about 15 minutes for a straightforward configuration.

1. Enable mailbox on the project. In the project settings, navigate to Integrations and enable the Project Mailbox feature. Onplana generates the project's mailbox address and displays it.

2. Configure sender authentication. For projects where you want to restrict input to specific external organizations, add their domains to the approved sender list. For open intake projects, leave the allowlist empty to accept authenticated mail from any sender.

3. Define routing rules. Start with the minimum: one rule for your primary use case (vendor change requests, client feedback, system alerts). You can add more specific rules after observing the pattern of inbound messages for a week. The triage queue is always available as a fallback.

4. Share the address. Add the project mailbox address to your standard vendor onboarding template, client kickoff materials, or system integration configuration. The address stays the same for the life of the project.

5. Set the default assignee. When no routing rule matches a specific assignee, the task is assigned to the project mailbox's default assignee. Set this to the PM or the team member who performs initial triage on external input.

For the first week, check the triage queue daily to see what is arriving and refine the routing rules accordingly. After the rules stabilize, the triage queue review frequency drops to whatever cadence makes sense for the project's external communication volume.

The full configuration options for project mailbox, including custom domain setup and advanced routing expressions, are documented on the Onplana features page. For projects where external communication is structured enough to benefit from a more formal discipline, the framework in discipline, goals, milestones, and status reporting covers how to design the communication structure before configuring the tooling.