For operations — start here
A configuration path for intake normalization, tag routing, connector delivery, and read-only history.
Build one controlled path from lead intake to routing, CRM delivery, and operational follow-up. This guide shows the order to configure and verify each layer without exposing customer data or credentials.
Why it matters
When supported sources are normalized before routing, the same rules can handle them consistently. Shadow mode lets you observe tag matches before they influence allocation, while Delivery history gives operations a bounded record when an external destination returns an unexpected result.
Where to work
Use Company -> Webhook keys for webhook intake credentials, Lead routing -> Tags and Source mappings for normalization and matching, and Company -> Connectors for outbound delivery and Delivery history.
Steps
- Choose the supported intake path and validate its required fields and credential before sending production data.
- Normalize source values with Source mappings so equivalent values reach the same routing rules.
- Configure tag groups, observe their effect in Shadow, and move to Enforce only after the matches reflect the intended operating policy.
- Create the CRM connector, run Test draft with synthetic data, save the reviewed revision, and activate that saved revision.
- Accept a new synthetic lead and inspect its separate outbound result in Delivery history before enabling the production source.
See it in HoneyFalcon
Operations shell with intake, routing, and connector navigation.
A reliable operations path
Start with an observable intake contract
Document which supported source sends the lead, which fields are required, and which credential authenticates the request. A valid intake creates one HoneyFalcon lead that can follow the same allocation policy as leads from other supported sources.
Use a synthetic record first. It should be easy to identify throughout routing and delivery without exposing a real prospect.
Normalize before you enforce
Source mappings turn equivalent source values into the values expected by your tag groups. Review those mappings before enabling stricter routing so spelling or formatting differences do not silently change who can receive a lead.
Shadow records how tag routing would classify new leads while current routing continues. Enforce applies the configured Preferred and Hard behavior to new leads, so promote only rules whose observed results match the intended policy.
Keep routing and CRM delivery separate
Lead acceptance establishes ownership inside HoneyFalcon. An active connector then creates a separate outbound delivery using its saved revision.
This separation makes the handoff easier to operate: a provider failure does not undo lead acceptance, and a successful routing decision is not presented as proof that an external system created the expected record.
Use the smallest useful support record
For routine diagnosis, capture the page, timestamp, visible state, Lead ID or Delivery ID, and the bounded response shown by HoneyFalcon. Rotate a credential if exposure is suspected; never add the complete secret or raw lead payload to a ticket or screenshot.
Validate the complete path with one synthetic lead before enabling a production source. For support, keep only the visible state, timestamp, Lead ID or Delivery ID, and the redacted response shown by HoneyFalcon.
Your operations path is ready when
- A synthetic lead enters through the intended source and carries the normalized values expected by the routing policy.
- Shadow evidence supports the decision to keep Shadow or move the reviewed tag rules to Enforce.
- The connector uses the intended saved revision, and a separate real delivery has a traceable result in Delivery history.
- An operator can investigate the workflow with bounded, non-secret evidence.