Guides › Integrations

Custom Signals & Tool Evidence

Custom Signals & Tool Evidence Put the extra fields your AI Agents send onto the lead, and turn the actions their tools record into a journey timeline and graded evidence. Find it: Settings > Custom Signals. admin only; tool evidence shows in any lead's drawer under Website Journey Before you start: An administrator role. The value already arriving with the session — a signal surfaces data your agents send, it does not create it. A decision about who should see it: signals are scoped by role. For tool evidence: your developer can send a tool's schema and one real sample, or your connected application can submit its own definitions if LeadLogiX has enabled tool submissions for this workspace.

Add a custom signal

Add a custom signal Start by asking whoever builds your AI Agents what the field is called. Get the field name from your Agent team Ask what key they send it under — for example partnerCampaignId , or preferences.tier for a nested value. Point the signal at it Metadata path = that name; a Label your team will recognise; Value type matching what they send — text, number or yes/no. Choose who sees it, and where Visible to roles decides who; Target tab decides which tab of the lead. LeadLogiX warns you if a role cannot see the chosen tab. Choose how it renders A field, a coloured badge for a short flag, or a metric with a unit and an aggregation (count, sum, average, min, max) under “Your metrics” in the Analytics Hub. Try each below. Open a lead that arrived after you saved The value is on the tab you chose. Older leads never get it. A name or type mismatch shows nothing A path that does not match what your Agents send arrives empty, and a wrong value type skips the value rather than showing it wrong. Neither raises an error.

Three ways to use a signal

Three ways to use a signal Pick a value and see how each one renders.

Want it to DO something? Use a Lead Tag on the same field

Want it to DO something? Use a Lead Tag on the same field Signals are display-only : they change what your team sees and never touch the LQI, price or identity. A Tag signal is a badge, not a Lead Tag — alerts, CRM sync and visibility key off Lead Tags. Both read the same data, so point a Lead Tag rule at the same field — path=sourceMetadata.partnerCampaignId , operator=exists — and one field does both jobs. See Tag on a field your agents send .

Tool calls and the Website Journey

Tool calls and the Website Journey A transcript records what someone said; a tool call records what they did. Illustrative payloads; the card, chips and wording are the shipped ones. Your developer sends the tool's JSON Schema and one real sample A genuine console sample of one call and one result. You say what each parameter means Which business fact it represents — the part only you can answer. You flag anything private Names, emails, phone numbers, addresses — withheld until the lead is purchased. Send it to the platform Email with the schema, the sample and your answers. Or a connected application submits the definition itself through the API. A LeadLogiX administrator sets the mapping and approves it. From then on, every new lead from that tool gets a journey row and graded evidence. Submitted definitions are listed under Settings → Connected Apps on the Tool Registrations tab — waiting for review, approved and in use, not approved (with the reason), turned off, or expired — and you are emailed at each change (switch notices off per type under Company profile → Notifications ). A waiting definition does nothing: its calls are recorded as unattributed observations. An approval affects new leads only. Calls from unregistered tools are retained verbatim and counted, so nothing is lost while you wait. The tool name must stay exactly stable Matching is case-sensitive: start_quote and Start_Quote are different tools, so a rename or casing change after a refactor silently ends the evidence. Have alternate names registered as aliases. A result sent as a list vanishes from the timeline A result body must be one JSON object. A bare list is kept for review but produces no journey row and no facts — the most common way a result silently goes missing. You'll know it worked: The signal renders in the form you picked — a field or badge on the next lead you open, or a total under “Your metrics” in the Analytics Hub. A registered tool's calls appear as rows on the lead's Website Journey card, in transcript order, with a detail line built from the mapped parameters. A new lead shows no signal value The field is not arriving under that exact name, or the value type does not match. You are looking at a lead from before you saved. If the name is right, it is a question for your Agent team, not a setting here. No Website Journey card at all No recognised tool activity on this lead. If other leads show calls kept for review, registration is the gap. A count of calls kept for review Those tools are unknown, disabled, or scoped to another workspace. Send the tool name and a sample. Rows appear but the detail line is empty The tool is registered, but no parameters are mapped to facts. Decide what they mean and have them mapped. Rows never say paired Only one side of each exchange is sent. Ask your developer to emit the result as a second turn for the same tool. Evidence stopped after a release Almost always a renamed or re-cased tool. Compare the mono tool name on old and new leads; register an alias. Why tool calls are graded evidence Anyone can say they are ready to buy; a booking either exists or it does not. That is why tool calls are graded as their own class of evidence, and why two workspaces running the same agent can produce leads of very different quality — the gap is usually whether the actions were registered. Rows come only from tool calls: nothing the customer said and nothing the model inferred can add one. Your team builds and calls whatever tools your agent needs. Turning calls into graded evidence stays a LeadLogiX decision — what a field is worth and how much a source deserves to be believed are set on the platform side so they mean the same thing across every workspace. A submitted definition is a proposal: it changes nothing until a LeadLogiX administrator approves it. Only some fact keys move the score — a contact vector, a budget corroboration, a target property, an intent signal; the rest are recorded faithfully and do not. Privacy is decided at registration: a payload cannot mark itself private or public. Measured on one mid-strength lead: with no tool evidence it scored below the pricing floor and was unsellable; one tool-captured budget lifted it to $51.83; adding a target property and an intent signal took it to $59.76. A tool-captured phone matters more still — with no contact vector, reachability is zero and the lead is worth nothing. Tool evidence can also rescue a lead the model judged to have no purchase intent. Nothing about the vocabulary is built in — labels are free text, so the same machinery carries any line of business. An insurer's run_risk_check becomes RISK CHECK (band: preferred); home services' schedule_survey becomes SURVEY BOOKED; legal intake's run_conflict_check becomes CONFLICT CLEARED; staffing's submit_candidate becomes CANDIDATE SUBMITTED; logistics' quote_freight becomes QUOTE ISSUED. If the timeline should read POLICY_QUOTED , that is what gets registered. Distinct actions want distinct tools, so a buyer reads a story rather than one blob. What the Website Journey card shows On the row Where it comes from What it tells the reader The event label The Journey Event Type registered for that tool What kind of action this was, in your business's words The small mono name The tool name exactly as your agent called it Which tool produced the row — the audit trail The detail line The parameters that were mapped, as name: value What was actually asked for or recorded A paired chip A call and its result sent as two back-to-back turns for the same tool The tool's answer was captured too, not just the request A direction chip How the platform decided this was a call or a result Provenance — whether your connector declared it or it was inferred A footer count Calls from tools that are unknown, disabled or out of scope How much evidence is waiting on registration Which of a tool's results count as evidence — and why to send the result side, declare the whole toolset and avoid a catch-all tool — is decided by whoever builds your agent. Point them at Tool calls as evidence → Mapping decisions . Worked example: partner campaigns, start to finish Your Agent team adds the field partnerCampaignId: "PC-4471" on each conversation — and leaves it out when there is no partner rather than sending it empty, which matters for step 4. You add the signal Settings → Custom Signals → Add . Metadata path partnerCampaignId , Label Partner campaign , Value type Text, preset Filterable tag, a colour, the roles who should see it. Save. Check the next lead The badge is on the tab you chose. Nothing there? The field is not arriving under that exact name. Add a Lead Tag so it DOES something Settings → Lead Tags → Add , rule path=sourceMetadata.partnerCampaignId , operator=exists — your Agents' field name, not the signal's. Count them A second signal on the same field, preset Track a metric, aggregation count — under “Your metrics” in the Analytics Hub. Fields suit working context (a preferred contact time, a school district); badges suit the one flag you want noticed; metrics give a quick pulse without a report. Keep procurement-only detail off the agent view, and vice versa.