How rules work, in depth
The four-step overview shows what happens to an email. This page shows how you configure it — the authoring experience behind every classification and action.
Build rules in plain English. No code, no scripts.
Describe what to look for, decide what to set, and pick what to do. kriyaflo handles the pipeline behind the scenes — you just author the logic a non-technical operator can read and change.
Describe the trigger in plain English
No regex, no SQL, no scripting. Write what you want to match — sender, subject, body, thread history, attachments, or any combination — and kriyaflo turns it into executable conditions.
- Natural language conditions with AND / OR
- Match across message, thread, and attachments
- Reference custom business data or prior labels
"If body contains 'invoice' OR 'billing' AND sentiment is negative, set priority to Urgent and route to Finance."
Choose what the AI should decide
Pick the attributes you want set automatically: category, priority, sentiment, owner, tags, confidence threshold. Each attribute can be rule-driven, AI-driven, or locked to a human override.
- Per-attribute confidence thresholds
- Source trace for every decision
- Human overrides always win
Map decisions to real actions
A rule doesn't stop at a label. It fires the next step — a ticket, a channel post, a task, or a webhook — with the email context pre-filled so the downstream tool already knows the story.
- Jira ticket, Slack post, Asana task, webhook
- Context auto-filled from email and thread
- Multiple actions per rule
Jira is live today. Slack, Asana, and Notion actions are on the roadmap — built on the same framework, so adding them doesn't require re-platforming your rules.
Preview before you publish
Test the rule against live or sample emails. See exactly what would be classified, who would be assigned, and which actions would fire — before the rule touches a real inbox.
- Dry-run against recent emails
- Simulated action output
- Confidence and source for each attribute
Deploy per inbox with layered policies
Apply the rule globally, to one inbox, or to a specific alias. Layer org-wide policies on top, then inbox-specific overrides — so support@ and billing@ can share a base and still diverge where it matters.
- Global + per-inbox policy stacks
- Draft / publish / rollback versions
- Changes apply without touching your email server