10 CRM Automation Recipes (copy-paste)
Ten event-triggered automations that survive contact with reality: stage-change notes, reply-to-advance, won alerts, enrichment queues, welcome emails, and a proposal follow-up drip - one JSON pack, valid against Relm's /v1/automations and /v1/sequences.
Who this is for
You run a pipeline - as a founder, a one-person RevOps team, or the builder of a CRM-operating agent - and you keep doing the same write after the same event. Deal moves, you type a note. A deal closes, you ping the team. That reflex work is what automations are for; the judgment calls stay with you or your agent.
The rule of thumb: automate anything where the trigger fully determines the action. If a human might decide differently based on context, keep it manual and have the automation leave a prompt instead (recipes 01, 07, and 08 do exactly that).
Four rules before you paste anything
1. Know your edge triggers from your level conditions. deal.stage_changed is an edge: it fires once per move. contact.updated and deal.updated fire on every save - a condition like replied = true stays true forever and re-fires on every later edit. Guard it: reset the flag as the last action (recipe 02) or check a done-marker the rule itself sets (recipe 09). Skip this and one prospect gets three welcome emails.
2. Fail loud at creation, not silently at runtime. A rule that references a missing stage, template, or field should be rejected when you create it. Relm does this: move_deal_stage to an unknown stage returns a 422 listing valid stage keys, and set_field requires the field to be registered first via POST /v1/fields - no auto-vivify. An agent cannot detect a rule that was accepted and then silently no-ops.
3. No chains. Automation actions in Relm write directly to the data and never re-emit events, so one automation cannot trigger another - loops are impossible by construction, and a stage move made by recipe 02 will not fire recipe 01. Every recipe below is complete on its own; multi-step behavior over time is a sequence (recipe 10), not a chain of rules.
4. Leave a paper trail. Any recipe that silently mutates data (set_field, move_deal_stage) also writes an activity note saying it did - silent writes are how CRMs rot. The stage-change playbooks take this to its logical end: a defined side effect for every move.
The 10 recipes
| # | Recipe | Trigger | Fires when | Actions |
|---|---|---|---|---|
| 01 | Stage change → next-step note | deal.stage_changed | any move | note: log next step within 24h |
| 02 | Reply flagged → advance | deal.updated | replied = true | move to negotiation, reset flag, note |
| 03 | Won → notify the team | deal.stage_changed | stage = won | email the team inbox, note |
| 04 | New lead → enrichment queue | contact.created | always | set enrichment_status = pending, note |
| 05 | New lead → welcome reply | contact.created | email exists | send acknowledgment email |
| 06 | High-value deal → founder review | deal.created | value_cents ≥ 2,500,000 | note + email the founder |
| 07 | Lost → post-mortem prompt | deal.stage_changed | stage = lost | set loss_review = pending, note |
| 08 | Qualified → qualification checklist | deal.stage_changed | stage = qualified | note with the eight MEDDPICC checks |
| 09 | Customer → onboarding kickoff | contact.updated | type = customer, not yet onboarded | mark onboarded, kickoff email, note |
| 10 | Proposal → 3-touch follow-up | deal.stage_changed | stage = proposal | drip at day 3, 7, 12; exits on any stage change |
Three deserve a closer look.
Recipe 02 answers "who marks replied?" - whatever watches your inbox: a reply-detection webhook or the agent triaging mail each morning sets custom_fields.replied = true on the deal. The automation does the rest and resets the flag, re-arming the rule for the next reply. Reply detection is an integration problem; reply handling is a CRM rule.
Recipe 08 drops a checklist note the moment a deal enters qualified, listing the eight MEDDPICC letters (the framework descends from MEDDIC, created by Jack Napoli and Dick Dunkel at PTC). It does not score anything - it makes forgetting impossible.
Recipe 10 is a sequence, not a rule, because it acts over time: it enrolls the deal's primary contact when the deal hits proposal, sends three escalating nudges (day 3, 7, 12), and exits the instant the deal leaves the stage. Relm re-checks exit conditions before every send and the moment the source deal changes, so a prospect who signed on day 4 never gets the day 7 email. The drip sequence recipes cover this pattern for welcome, nurture, and onboarding flows.
Missing on purpose: "deal idle for 14 days." That is a scheduled sweep, not an event - agent work. Pair this pack with the daily pipeline review agent prompt: rules handle the moments, the agent handles the silences.
The pack
Prerequisites, in order: your pipeline needs the stage keys qualified, proposal, negotiation, won, lost (remap the values below if yours differ); the four custom fields must be registered before the automations that use them; email actions need a connected sending key (POST /v1/connections) - test-mode sends are simulated, never delivered. Post fields entries to /v1/fields, automations to /v1/automations, sequences to /v1/sequences.
{
"fields": [
{ "object": "deal", "key": "replied", "data_type": "boolean" },
{ "object": "deal", "key": "loss_review", "data_type": "text" },
{ "object": "contact", "key": "enrichment_status", "data_type": "text" },
{ "object": "contact", "key": "onboarded", "data_type": "boolean" }
],
"automations": [
{
"name": "01 Stage change -> next-step note",
"trigger_event": "deal.stage_changed",
"conditions": [],
"actions": [
{ "type": "create_activity", "activity_type": "note", "body": "Deal '{{title}}' moved to {{stage}}. Log the next step and its owner within 24 hours." }
]
},
{
"name": "02 Reply flagged -> advance to negotiation",
"trigger_event": "deal.updated",
"conditions": [
{ "field": "replied", "op": "eq", "value": true }
],
"actions": [
{ "type": "move_deal_stage", "stage": "negotiation" },
{ "type": "set_field", "field": "replied", "value": false },
{ "type": "create_activity", "activity_type": "note", "body": "Prospect replied. Auto-advanced to negotiation." }
]
},
{
"name": "03 Won -> notify the team",
"trigger_event": "deal.stage_changed",
"conditions": [
{ "field": "stage", "op": "eq", "value": "won" }
],
"actions": [
{ "type": "send_email", "to": "[email protected]", "subject": "WON: {{title}}", "body": "{{title}} just closed at {{value_cents}} cents. Start the onboarding handoff." },
{ "type": "create_activity", "activity_type": "note", "body": "Won. Handoff to onboarding started." }
]
},
{
"name": "04 New lead -> enrichment queue",
"trigger_event": "contact.created",
"conditions": [],
"actions": [
{ "type": "set_field", "field": "enrichment_status", "value": "pending" },
{ "type": "create_activity", "activity_type": "note", "body": "New lead. Enrich before first touch: company, role, source, one personal hook." }
]
},
{
"name": "05 New lead with email -> welcome reply",
"trigger_event": "contact.created",
"conditions": [
{ "field": "email", "op": "exists" }
],
"actions": [
{ "type": "send_email", "subject": "Got your message, {{first_name}}", "body": "Hi {{first_name}}, thanks for reaching out. A real person reads every one of these - you will hear back within one business day." }
]
},
{
"name": "06 High-value deal -> founder review",
"trigger_event": "deal.created",
"conditions": [
{ "field": "value_cents", "op": "gte", "value": 2500000 }
],
"actions": [
{ "type": "create_activity", "activity_type": "note", "body": "High-value deal: {{value_cents}} cents. Founder reviews pricing and owner before the first proposal." },
{ "type": "send_email", "to": "[email protected]", "subject": "Review before proposal: {{title}}", "body": "New deal over the review threshold: {{title}}. Check pricing, owner, and close plan before it advances." }
]
},
{
"name": "07 Lost -> post-mortem prompt",
"trigger_event": "deal.stage_changed",
"conditions": [
{ "field": "stage", "op": "eq", "value": "lost" }
],
"actions": [
{ "type": "set_field", "field": "loss_review", "value": "pending" },
{ "type": "create_activity", "activity_type": "note", "body": "Lost. Record the reason before archiving: price, timing, competitor, or no decision." }
]
},
{
"name": "08 Qualified -> qualification checklist",
"trigger_event": "deal.stage_changed",
"conditions": [
{ "field": "stage", "op": "eq", "value": "qualified" }
],
"actions": [
{ "type": "create_activity", "activity_type": "note", "body": "Entered qualified. Score it: metrics, economic buyer, decision criteria, decision process, paper process, pain, champion, competition." }
]
},
{
"name": "09 Contact becomes customer -> onboarding kickoff",
"trigger_event": "contact.updated",
"conditions": [
{ "field": "type", "op": "eq", "value": "customer" },
{ "field": "onboarded", "op": "empty" }
],
"actions": [
{ "type": "set_field", "field": "onboarded", "value": true },
{ "type": "send_email", "subject": "Getting you set up", "body": "Hi {{first_name}}, welcome aboard. Next steps: kickoff call this week, account setup, first review at day 30. Reply with two times that work for the kickoff." },
{ "type": "create_activity", "activity_type": "note", "body": "Converted to customer. Kickoff email sent - schedule the call." }
]
}
],
"sequences": [
{
"name": "10 Proposal sent -> 3-touch follow-up",
"trigger": {
"event": "deal.stage_changed",
"filter": [
{ "field": "stage", "op": "eq", "value": "proposal" }
]
},
"exit_when": [
{ "field": "stage", "op": "neq", "value": "proposal" }
],
"steps": [
{ "wait_days": 3, "subject": "Thoughts on the proposal?", "body": "Hi {{first_name}}, checking in on the proposal - any questions I can answer? Happy to walk through the numbers on a short call." },
{ "wait_days": 4, "subject": "The question everyone asks", "body": "Hi {{first_name}}, the most common question at this point is about implementation effort. Short answer: less than you think. Want the long answer on a 15-minute call?" },
{ "wait_days": 5, "subject": "Should I close the file?", "body": "Hi {{first_name}}, if the timing is off, no problem - say the word and I will stop here. If it is still live, what is the next step on your side?" }
]
}
]
}
Shape notes: {{field}} placeholders interpolate from the triggering entity and its custom fields - deal rules can use {{title}} and {{value_cents}}, while sequence steps render against the enrolled contact (stick to {{first_name}} there). Conditions are a flat AND list; ops are eq, neq, in, nin, exists, empty, contains, gt, lt, gte, lte. Email actions without an explicit to go to the triggering contact, or the deal's primary contact. wait_days are gaps between steps, not offsets from enrollment.
Apply it with your agent
Hand the pack to an agent connected to Relm's MCP server (https://api.relmcrm.com/mcp - setup in the docs) with this prompt:
Install this CRM automation pack in my Relm workspace. Use test mode first.
1. Call the schema discovery tool and check my default pipeline has the stage
keys: qualified, proposal, negotiation, won, lost. If mine differ, remap
the stage values in the pack to my keys and show me the mapping.
2. Register the four custom fields from "fields".
3. Create the nine automations from "automations" and the sequence from
"sequences". Replace [email protected] and [email protected]
with my real addresses (ask me).
4. Verify: list automations and sequences, confirm 9 + 1 enabled, and run
one test - create a test-mode deal, move it to proposal, and show me the
sequence enrollment and its schedule.
Then wait for my OK before repeating in live mode.
Or install a single recipe by hand - safe to retry thanks to the idempotency key:
curl https://api.relmcrm.com/v1/automations \
-H "Authorization: Bearer relm_test_..." \
-H "Content-Type: application/json" \
-H "Idempotency-Key: recipe-01-stage-note" \
-d '{
"name": "01 Stage change -> next-step note",
"trigger_event": "deal.stage_changed",
"conditions": [],
"actions": [{ "type": "create_activity", "activity_type": "note",
"body": "Deal {{title}} moved to {{stage}}. Log the next step within 24 hours." }]
}'
Everything here is discoverable at runtime: GET /v1/automations-capabilities returns the exact trigger events, condition ops, and action types, so an agent can compose valid rules without this page - the core argument of what makes a CRM work for LLMs.
FAQ
Do I need Relm to use these recipes?
No. Each recipe is a trigger + conditions + actions rule, and that model maps onto HubSpot workflows, Pipedrive automations, Attio, or anything you build yourself. The JSON in this pack is shaped for Relm's POST /v1/automations endpoint, which is the fastest way to install all ten - an agent or a curl loop does it in under a minute.
Why is there no "deal idle for 14 days" recipe?
Because these automations are event-driven: they fire when a record is created, updated, or changes stage. "Nothing happened for two weeks" is not an event - it is a scheduled sweep, and it belongs to a daily agent run that lists deals, checks last activity, and acts. Use the Daily Pipeline Review agent prompt for that half of the system.
Can one automation trigger another?
In Relm, deliberately not. Automation actions write directly to the data and do not re-emit events, so chains and loops are impossible by construction. When recipe 02 moves a deal to negotiation, recipe 01 does not fire off that move. Design every recipe to be complete on its own - if you find yourself wanting a chain, you want a sequence or an agent instead.
What happens if a recipe references a stage or field that does not exist?
Creation fails loudly with a 422 that lists the valid options - Relm validates referenced stages, pipelines, templates, and custom fields when the rule is created, not silently at runtime. That is why the pack registers its four custom fields first, and why you should remap stage keys like negotiation or proposal to your own pipeline before posting.
Will these automations fire on a bulk import?
Not in Relm: the batch endpoint (POST /v1/batch, up to 100 ops) is event-silent by design, so importing 5,000 contacts will not send 5,000 welcome emails. If you want recipes 04 and 05 to run for new records, create them individually through POST /v1/contacts. This is a safety default worth checking in any CRM before you import.
Install the pack in test mode
1,000 requests a month on the Free plan, no card. See pricing.
Start free →