Skip to content
Plain Help Center home
Plain Help Center home

Workflow rules

Workflow rules allow you to automate actions to speed up your workflow, including auto-triage, prioritization, labelling of incoming support requests, and much more.

Available on the Expansion plan and higher. Interested? Contact sales or message us in your shared Slack channel.

workflow-rules.png

How to create a workflow rule

Go to Settings → Workflow rules to create or manage your rules.

Every workflow rule has two parts:

1. Conditions

Conditions determine when the rule should run. You can add one or more conditions, and choose whether all conditions must match or any of them.

You can also negate any condition (e.g. “does not have label”) and combine multiple conditions of the same type (e.g. “has label X” and “does not have label Y”).

Rules can be triggered based on:

  • a specific label;

  • a customer tier or company;

  • a specific support address (e.g. security@, sales@);

  • a Slack or other support channel (email, chat, API, MS Teams);

  • a keyword in the message body (e.g. “outage”, “urgent”);

  • a tenant or linked organisation;

  • an AI prompt match – describe the trigger using natural language;

Use the AI prompt match field to describe triggers in plain language and match requests by intent, not just keywords, such as “customer is blocked and needs help urgently” or “request is about trial extension”.

It’s perfect for B2B teams dealing with a huge variety of requests that don’t follow a rigid structure.

2. Actions

Once a condition is matched, perform one or more of the following:

  • assign the thread to a teammate

  • set the thread status (e.g. open, snoozed)

  • set the customer tier

  • apply labels

  • set the thread priority

  • add the customer to a customer group

  • add an internal note to the thread

  • making a HTTP request to a remote endpoint

The Send HTTP request action

One of the most interesting actions we provide allows you to make HTTP requests to a remote endpoint.

To configure this action, you need a URL, along with optional headers and a body (JSON serialisable). When this action triggers, Plain will make a POST HTTP request to the given URL, with the provided headers and body.

You can interpolate the following variables in the body:

  • customer.email

  • customer.fullName

  • customer.shortName

  • thread.ref

  • thread.id

  • thread.externalId

  • thread.title

  • thread.description

For instance, you could very easily use this action to trigger a pager when a thread is labelled with e.g. critical . A good choice for the body would be:

{
  "threadId": "{{ thread.id }}"
  "threadTitle": "{{ thread.title }}"
}

The headers you provide will be included as part of the HTTP request, so you could use them, for instance, to authenticate your requests (with a shared secret).

These HTTP requests use the same security measures, response handling and retry policy as our webhooks.

Example use cases

  • Assign all enterprise-tier threads to a dedicated account manager

  • Ignore threads that match common spam patterns automatically

  • Prioritize messages containing “outage”, “blocked”, or “vulnerability”

  • Route demo or trial-extension requests to sales

  • Send all security@ or privacy@ emails to your security lead

Managing rules

You can view, edit, or temporarily disable rules from Settings → Workflow rules. Disabling a rule doesn't delete it, but pauses it – it won't trigger while paused.

Powered by Plain