Create Tasks via Email

ClientCove can accept inbound email and turn each message into a task — with the sender resolved to a portal user, the client scoped automatically, the subject becoming the task title, and the body becoming the task notes. Email-driven workflows let your team capture work without switching tools.

How Inbound Email Works

The flow:

1. An MX record on a subdomain (typically inbound.yourdomain.com) routes mail to SendGrid Inbound Parse
2. SendGrid POSTs each parsed email to a ClientCove webhook (/wp-json/clientcove/v1/inbound-email)
3. ClientCove looks at the local part of the recipient address (the bit before @) and matches it against your configured routes
4. The matched route determines whether to create a Ticket or a Task, plus the default priority and client
5. The sender is resolved to a portal user (or rejected if Sender Security is on and they're unknown)
6. A new task is created with the email subject as the title, the body as notes, attachments as media library files, and any tokens (for:, client:) applied

The same machinery handles tickets — the route's Creates dropdown decides which post type gets created.

Setting It Up

Go to Settings → Inbound Email to find the configuration tab.

The page has these sections:

SendGrid Inbound Parse Configuration

ClientCove uses SendGrid as the email-receive infrastructure. To wire it up:

1. DNS — add an MX record

In your DNS provider, add an MX record for the subdomain you'll use for inbound mail (e.g. inbound.yourdomain.com):

The subdomain name doesn't matter to ClientCove — inbound., mail., in., or even your root domain all work as long as DNS points to SendGrid. The literal word inbound is just convention.

2. SendGrid — add the host

In SendGrid → Settings → Inbound Parse, click Add Host & URL and configure:

Save. SendGrid is now relaying parsed emails to ClientCove.

3. ClientCove — set the inbound domain

In the Inbound Domain field, enter the subdomain you used (e.g. inbound.yourdomain.com). This is purely cosmetic — it's used to display address fields like tasks@inbound.yourdomain.com in the UI and the setup instructions. Routing is matched against the local part only, so this field is for human readability.

Adding a Task Route

A route maps an email local-part to a content type with default settings.

1. Click Add Route at the bottom of the routes list (or use one of the two default routes that ship — support for tickets, tasks for tasks)
2. Configure the new row:

3. Click Save Settings at the bottom of the form

Multiple task routes

Nothing stops you from having multiple Task routes — each scoped to a different default client. Common pattern:

• tasks@inbound.… — generic inbox, no default client
• acme@inbound.… — pre-scoped to Acme Corp via Default Client
• globex@inbound.… — pre-scoped to Globex via Default Client

Senders just email the right address, no tokens required.

Email Tokens

Inside the subject or body of an email to a Task route, these tokens override the defaults. They're stripped from the title/notes before saving so they don't show up in the final task.

Examples

Send to yourself, scope to a client:

To: tasks@inbound.yourdomain.com
Subject: client:acme-corp Review Q2 brief
Body:
Need to read through and provide feedback by EOW.

Result: a task in your queue titled "Review Q2 brief", scoped to Acme Corp, notes = "Need to read through…"

Delegate to another user:

To: tasks@inbound.yourdomain.com
Subject: for:jane@example.com Update the staging banner

Result: a task assigned to Jane (instead of you), titled "Update the staging banner".

Combine both:

To: tasks@inbound.yourdomain.com
Subject: for:bob@example.com client:"Globex Industries" Schedule a kickoff call

Result: a task assigned to Bob, scoped to Globex Industries, titled "Schedule a kickoff call".

Tokens can appear in either the subject or the body. Tokens of the same type can appear multiple times — the first match wins.

Sender Resolution

The sender's email is matched against portal users in this order:

1. Look up wp_users by email — exact match
2. If found, the task is assigned to that user
3. If not found and Sender Security is on, the email is dropped silently (no task created, logged in the inbound log)
4. If not found and Sender Security is off, the task author falls back to the current admin user

If the email contains a for: token, the assignee resolution runs against the token value first; the sender lookup only applies if the token can't be resolved.

Client Resolution

ClientCove resolves a task's client through a four-step chain:

1. client: token — explicit override in the email
2. Sender's user → assign_to_client — the sender's profile has a client assigned
3. Sender email domain match — the domain of the sender's email matches a client's configured domain (if you've populated client domains)
4. Route Default Client — last-resort fallback set on the route

The first non-empty match wins. If all four come up empty, the task is created with no client assignment.

This makes it easy to set up "send any email from @acme-corp.com and it lands in their bucket" without your team having to type tokens.

Attachments

Attached files are saved to the WordPress media library and linked to the task as references.

Limits

• Max size per attachment: 25 MB
• Allowed types: PDF, JPEG, PNG, GIF, WebP, DOC, DOCX, XLS, XLSX, plain text, CSV, ZIP

Files exceeding the size or with disallowed types are skipped silently and logged to PHP error logs.

For attachments to come through, you must enable POST the raw, full MIME message in the SendGrid Parse host configuration.

Confirmation Emails

When Confirmations is enabled, ClientCove auto-sends a confirmation email to the sender after a task is created. The confirmation includes:

• The task ID
• A link to view the task in the portal

Disable this if you're using inbound email for high-volume programmatic workflows where confirmations would be noise.

Sender Security

The webhook URL is public — SendGrid posts to it without authentication, because it's the standard Inbound Parse contract. Without security, anyone who learned the webhook URL could POST to it and create tasks owned by your admin user.

Recommendation: turn on the toggle.

When Only accept emails from registered portal users is on:

• Emails from sender addresses that don't match a wp_users row are dropped
• The drop is logged to the inbound log so you can see what was rejected
• This eliminates the abuse vector

Leave it off only if you genuinely need to accept email from unregistered senders (e.g. a public intake address).

The Inbound Log

The bottom of the Inbound Email settings page shows a live log of recent webhook hits — successful and failed — so you can troubleshoot routing.

Each row shows:

• From — sender address
• To — recipient address (the local part determines the route)
• Subject — email subject (cleaned of tokens)
• Action — what was created (task, ticket) or why it was dropped (rejected: unknown sender, no route matched, etc.)
• Result — link to the created task / ticket, or an error message
• Time — when it arrived

Use the log to verify your DNS / SendGrid setup the first time you wire it up. Send a test email and watch it appear within a few seconds.