missive api rule failed to execute

TL;DR

A Missive rule is conditions plus actions, and execution fails when the conditions match something the actions can't handle, or when an action references a deleted label, mailbox, or user. Debug it like a small program: run the rule against a known conversation, watch which action fails, and fix the reference. Rules rot as teams rename things.

The query

missive api rule failed to execute

Use this when

• A Missive rule fails silently or with an error
• A rule works for some conversations but not others
• A newly created rule never fires

Not for

• Missive API authentication errors
• Conversation sync issues
• Missive webhook delivery problems

Steps

1. Run the rule manually on a test conversation

Apply the rule by hand to a conversation that should match. Watch each action execute. The failing action is usually obvious: assigning to a deleted user, applying a deleted label, or moving to a removed mailbox.

Expected output: the specific failing action identified.

2. Check every referenced object still exists

Walk the rule's actions and confirm each label, mailbox, user, and team still exists and is spelled as the rule expects. Renames are the classic rot: the label 'urgent' became 'p1-urgent' and the rule kept the old name.

Expected output: every referenced object confirmed present.

3. Verify the conditions match the intended conversations

Read the rule's conditions against a conversation that should match and one that shouldn't. Overly narrow conditions (an exact subject match) silently exclude; overly broad ones fire where they shouldn't. Adjust and retest.

Expected output: the rule firing for exactly the intended conversations.

4. Check rule order and conflicts

An earlier rule may move or close the conversation before yours runs, or two rules may fight over the same conversation. Review the rule list in execution order with a test conversation.

Expected output: no earlier rule intercepting the test conversation.

Variant phrasings

missive rule not working

Steps 1 and 2: manual run first, then the reference audit.

missive automation rule error

Step 4's order check catches rule-on-rule interference.

Why it happens

Rules reference the workspace as it was when they were written: labels, mailboxes, teammates. Workspaces change weekly and nobody updates the rules, so actions point at ghosts. The rule engine fails the action rather than guessing, which is correct but silent enough that teams notice weeks later.

Edge cases

• Rule changes need a test conversation. Untested rules are wishes.
• API-created rules can carry ids the UI doesn't show. Audit both surfaces.
• Log rule executions somewhere visible. Silent rules fail silently.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstbEFFxETDB5bpCUclZEvmw