Contacts the app creates don't come back as new leads

Every CRM contact the platform creates is tagged and added to a suppression list, so the account's own CRM automations cannot bounce it back as a fresh lead.

What it is

Contact creates carry a system tag that tenant workflows can exclude from new-lead triggers, and the created contact id is registered in a suppression table that the lead sync consults before minting a card.

Also called: echo guard · lead loop · l2b-app tag · my own contact became a lead

See it
Contacts the app creates don't come back as new leads
✓
Dirt work
✓
Foundation
✓
Framing
✓
Roofing
5
Trim
4 photos
6
Final
A loop diagram with the return arrow cut by a shield labelled 'l2b-app'. Sample data — no customer information appears here.
How it works
  1. 1The messaging adapter creates a contact in the account's location.
  2. 2The payload includes the l2b-app system tag.
  3. 3The new contact id is passed to the suppression writer.
  4. 4The lead sync's first verdict check is the suppression list, so the contact can never round-trip into the pipeline.
Why we built it

The comment states the loop being closed: 'Echo guard: a contact WE minted must never round-trip back into the pipeline as a "new lead" via the tenant's GHL automations', paired with the tag's purpose — it 'lets tenant GHL workflows exclude app-created contacts from "new lead" triggers'.

The problem
  • Messaging a customer could create a CRM contact that the tenant's own automation treated as a new lead.
Sound familiar?
What you get
No self-inflicted duplicate leads from ordinary messaging.
Tenant-side CRM workflows have a tag they can filter on.

See it on your own jobs

Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.

or keep browsing features →