01 / INDEPENDENT PROJECT · MY OWN INTERNAL WORKFLOW
One reply.
A shared stop.
I built shared reply checks so that a response detected on one channel can stop a queued follow-up on the other. The hard parts were identity, freshness and knowing whether an action actually happened.
- Owner & builder
- Valdeir Lima / Mako
- Tools
- n8n, Supabase, Python, APIs
- Evidence
- September 2026 operating and test records
The problem
Separate email and LinkedIn queues can act on different information. A person may reply in one place while a follow-up remains queued elsewhere.
For my own business, I needed one shared record of replies and suppression, plus a final check before an outbound action. A missing inbox scan had to mean “hold”, rather than an assumption that no reply existed.
SIMPLIFIED ARCHITECTURE
- 01Retrieve repliesGmail watcher and bounded LinkedIn conversation reads
- 02Match identityCanonical profile identity and mapped email addresses
- 03Record the stopSupabase stores shared reply and suppression state
- 04Guard the actionReply, suppression or stale evidence holds the send
What I implemented
I connected reply events to a shared suppression store, added final outbound guards to the connected channels and preserved the original event evidence. I also documented the checks and investigated uncertain delivery states.
- Match identities, not similar names. Canonical LinkedIn profile identity and mapped email addresses establish the connection. A shared name or company alone is insufficient.
- Hold when evidence is stale. The guards check required inbox scans and mirror health. Database errors or missing freshness evidence prevent a send.
- Keep event processing repeatable. Reprocessing a reply should preserve one consistent stop state. Event history remains available to explain the decision.
VERIFICATION RECORDED IN SEPTEMBER 2026
Check the failure paths.
The operating notes document real database checks using rolled-back fixtures. They did not send email or LinkedIn messages. The table summarises those recorded checks; it is not a new production test or a public execution log.
| Condition | Behaviour checked |
|---|---|
| Reply received in Gmail | Matched LinkedIn outbound action is blocked. |
| Reply retrieved from LinkedIn | Matched email queue is stopped through shared suppression. |
| Same reply processed again | Duplicate synchronisation is handled idempotently. |
| Stale scan or unavailable database | Sending is held until required evidence is available. |
| Identity mismatch | A similar name does not establish a contact match. |
A real recovery decision
One invitation existed in LinkedIn, but the worker could not confirm it. I checked the native sent state, preserved the original attempt and reconciled its receipt without sending again. Uncertainty required investigation, not an automatic resend.
What this proves
and what it doesn’t.
This is evidence of integration, testing and troubleshooting in my own operational project. It is not a paid client case, a revenue result or proof of meetings generated.
Detection is delayed. Gmail polling was configured every 15 minutes. The LinkedIn mirror copies saved messages; it is not a live inbox reader. Bounded conversation reads can leave replies undetected for hours, and paused or offline workers do not read them. The shared stop applies after retrieval and matching.
The original operating records are internal. This public summary omits contacts, message bodies, account identifiers and credentials. It does not claim that every implementation detail has been independently reproduced from public source.