Keep CRM accounts updated
Companies already in your CRM are watched for legal events, flagged before a rep ever walks into a call blind.
- TriggerTriggered
Weekly schedule
- CompletedSalesforce
Pull the accounts you already hold
- Completed
BODACCCheck what's been published
- CompletedClaudeChatGPT
Keep only what changes a decision
- CompletedSalesforce
Write it back
A CRM decays quietly. The record is not wrong on the day it is written; it is wrong eighteen months later, and nothing announces it. The company was acquired, changed name, moved, or filed for protection — all of it published, none of it in your CRM.
BODACC publishes those events continuously. The gap has never been availability. It is that nobody reconciles a public feed against an internal database every week by hand.
What you get
Accounts that moved, whether new ownership, a name change or an insolvency filing, surface the week it happens instead of the quarter after.
The part worth getting right
Most legal events are noise for a sales team. Publishing all of them into the CRM trains everyone to ignore the flag. Filtering to the handful that change how you would run the account is what makes the difference between a signal and a second inbox.
The prompt
The real prompt behind the steps above — detailed enough that an agent with a people-search tool, email/phone enrichment, and CRM access can run it as written.
# Keep CRM accounts from going stale
You have read/write access to Salesforce and a tool that queries
BODACC (the French legal-announcements registry) for company events.
Run this on a recurring schedule.
## 0. Set up (skip if you're already connected)
If you don't already have live tool access for this, connect it first
— this prompt is only as real as the tools behind it:
1. Create a free account at app.tulina.ai.
2. Add Tulina's MCP server to your assistant: https://mcp.tulina.ai/mcp
3. In Tulina, connect your own API keys for the tools this prompt
uses — Salesforce and BODACC.
Once connected, your assistant has real tool access and the rest of
this prompt runs as written.
## 0b. Already on Tulina? Three things around the run
An account and the MCP server are not the whole setup. Two of these come
before the run below and one after it, and together they turn this from a
one-off answer into a process your workspace keeps:
1. **Activate this process's connectors first.** Call
`oto_connector(op="list")`, match it against the tools named in step 3
above, and `oto_connector(op="select", name="...")` every one that
isn't active yet. Selecting a connector does not mount its tools in the
conversation you're already in — reach them through `oto_call` for this
run, or open a fresh conversation once they're all on.
2. **Attach the work to an existing project.** `oto_project(op="list")`
shows your active org's projects: pick the one this work belongs to
rather than opening another, and keep its id. The project is where this
process, the tables it writes to and the connectors it uses hang
together.
3. **When the run is done, save it as a process — with its graph.** Write
the body with `oto_procedure(op="set", ...)`, then attach it with
`oto_project(op="link", project_id=..., target_type="procedure",
target_ref="<your slug>")`. The body has to carry a drawing: read
`oto_guide(op="read", slug="procedure-flowchart")` and follow it
exactly — ONE untagged fenced block in that grammar, opening with the
trigger and a quoted example of what you'd type to start a run. Tulina
parses that drawing back into the graph it renders as the process's
default view, which is what makes it come out in the same style as
every other process in the app; a drawing the grammar can't read falls
back to raw characters instead. Saving a process needs org-admin
rights — without them, hand the finished body to someone who has them.
## 1. Pull the accounts you already hold
- Query Salesforce for every Account carrying a SIREN (or your own
French-company identifier field), in batches — never one record at
a time.
- If your CRM tracks when an account was last checked, pull only what's
due; otherwise pull the full set each run and let the registry's own
"since date" filter in the next step keep the volume down.
## 2. Check what's been published
- For each SIREN, query BODACC for legal announcements published since
the last run (or, on a first run, the last 90 days).
- Batch this by SIREN list where the tool supports it; fall back to
one call per company only if it doesn't.
## 3. Keep only what changes a decision
- Filter to event types that actually change how a rep would run the
account: ownership change, name change, address change,
insolvency/collective proceedings, officer changes. Drop routine
filings (annual accounts, minor administrative notices) — publishing
everything trains the team to ignore the flag.
- If an account has more than one qualifying event since the last run,
keep all of them — don't collapse to "most recent only."
## 4. Write it back
- Update the Account's status/flag field and leave a note naming the
event type and its publication date — not just "something changed."
- Only touch accounts that actually had a qualifying event this run;
never touch the rest.
- If this runs on a schedule, record the run's cutoff date somewhere so
the next run knows where to pick up.
## Output
Report: how many accounts checked, how many had a qualifying event
(broken down by event type), and any SIREN that failed to resolve in
BODACC.
Questions about this process
Related processes
- Qualify inbound leads
Every new lead is matched to its legal entity, scored on real headcount and filed accounts, and written back before a rep opens it.
- Source and qualify leads
A target company gets searched across LinkedIn, ranked against your ICP, and the qualified shortlist lands in your CRM with email and mobile filled in.