AltScore
Nodes

Signal (Goal)

The Goal node does two independent things when the flow passes through it, and you can use either one, both, or neither.

  • Goal to measure. It records that this conversation reached a goal from the tenant's goal catalog. Goals are what Conversation Insights counts: flow completion, the funnel and the journey funnel are all built from them.
  • Signal. It writes a typed value (with history) on the borrower, optionally scoped to a deal. It mirrors how metrics work, and it is what other systems query about the customer.

With neither configured it behaves like the legacy Goal node: a visual label on the canvas with no effect.

Configuration

OptionDescription
goalKeyGoal from the goal catalog (Settings → Data Models → Goals). Leave empty to measure nothing
GoalNameLabel of the node on the canvas, kept from the legacy Goal node. Never counted as a goal
signalKeySignal from the data-models catalog (Settings → Data Models → Signal). Leave empty for a plain marker
valueLiteral value or a flow variable ({{key}}), rendered at runtime. Defaults to true
dealModenone (borrower-level), borrower (resolve the borrower's deal at runtime) or fixed (a specific deal)
dealStepKeyWith dealMode: borrower, filters candidate deals by step; most recent wins
createDealIfMissingWith dealMode: borrower, creates the deal (and its contact link) when none exists
dealContactRoleRole (from the deal_role catalog) used when linking the borrower to a created deal
dealIdWith dealMode: fixed, the concrete deal
lookupByborrower (default, the conversation's customer) or borrower_id with borrowerIdVariable, the variable holding the ID of the customer to write on
isTestTest signal in the panel. Marks as test data both the signal and the goal recorded by this node, so neither reaches production queries or Conversation Insights. Defaults to false

Signal keys are managed in Settings → Data Models → Signal; give each one a dataType so the stored value is typed correctly. The value input adapts to that type.

Goal to Measure

The Goal section of the panel, above the signal, lists the goals of the tenant's catalog by name and key. Pick one and every conversation that passes through the node records that goal. If the goal you need does not exist yet, Create goal opens the data-model form already set to the goal type, so you do not have to leave the editor. Once a goal is selected, the card on the canvas shows the goal's name.

Goals live in Settings → Data Models → Goals and belong to the tenant, not to a flow: the same goal can sit in several flows, and a flow can have as many goals as you need. Each goal has:

  • a key, the identifier the node stores (documents_received, contract_signed). It cannot be changed after the goal is created, so choose it with care;
  • a name, the text Conversation Insights shows. You can rename a goal at any time and the reports pick up the new name;
  • an optional description, to explain what reaching it means;
  • an optional order, used to sort the goals of a flow in its funnel (see Conversation Insights).

When the conversation reaches the node, the goal is recorded first, before the signal, the deal or anything else the node does, and the record depends on none of them: it is written whether or not the conversation has identified a customer yet, and whether or not the signal could be written. The first time a conversation reaches a goal, the node also leaves an info notice on it, goal_reached (Meta alcanzada: name), so you can see in Chat where each goal was reached. Later passes through the same goal are recorded too, but leave no new notice, so a loop never fills the conversation's notices. Then the node does everything else it already did, exactly as before.

Recording a goal never blocks the flow. If it fails, the node leaves a warning notice naming the goal and the conversation moves on.

Signal and goal answer different questions. A signal is a fact about the customer that other systems read ("offer shown: true"). A goal is a milestone of the conversation that you want to count across customers ("how many reached the contract signature this month"). When a step is both, configure both on the same node.

Which Customer Is Written

By default the node writes the signal on the conversation's customer, the one Login or Create Borrower bound to the conversation. Every flow published before this option existed keeps doing exactly that.

Choose Customer ID from a variable and the node records the signal (and, with dealMode: borrower, resolves that customer's deal) on another customer: the one whose ID sits in the flow variable you pick. The typical case is a guarantor or co-signer that Create Borrower created a few nodes earlier, leaving its ID in a variable. The ID is checked to exist in the tenant before anything is written.

This mode never falls back to the conversation's customer: an empty variable, one no node wrote, or an ID that is not in the tenant leaves a notice naming what to fix and nothing is written. Publishing is blocked when Customer ID from a variable is selected and the variable is empty.

This choice only affects the signal and the deal. The goal always belongs to the conversation that passed through the node.

When to Use It

Measuring how far customers get. Place a Goal node with a goal after each milestone of the flow: documents received, identity verified, contract signed. Conversation Insights turns them into the flow's funnel and its completion rate.

Recording a state other systems query. Use a signal ("kyc_completed", "offer_accepted") when a workflow, a report or another flow needs to know that the customer got there.

Tracking per-deal progress. A signal with a deal mode attaches the milestone to the customer's deal instead of the customer.

If you only want a visual label on the canvas, place the node without selecting a goal or a signal key.

Output Handles

Signal has one input and one output; it advances to the next node when one is connected. A Goal node with nothing connected to its output, typically the last milestone of a flow, still records its goal and leaves its goal_reached notice; then the flow ends with the warning any node leaves when nothing follows it. Recording failures never block the flow — they leave a notice instead.

Things to Know

Only nodes with a goal are measured. The goal name typed on older Goal nodes is a label and nothing else; Conversation Insights does not count it, and it does not count a signal on its own either. A flow published before goals existed has none until you add them.

Every pass is recorded. A flow that loops through the node, or a customer who goes through the flow twice, records the goal again. Reports count distinct customers, so repeats do not inflate the numbers.

Test conversations stay out of the reports. A goal recorded while you test the draft version, on a conversation hidden from Chat, or on a node with Test signal turned on is marked as test data and left out of Conversation Insights.

A deleted goal keeps its history. Deleting a goal from the catalog does not erase what was already recorded. A node that still points at it keeps recording it, with the key as its name; the first time a conversation reaches it, the node leaves the goal_reached notice followed by a warning, and later passes leave neither. The panel shows Deleted or unknown goal: key until you pick another one. Reports show a deleted goal with the name saved in its most recent record written while it was still in the catalog, from any flow and including test passes: the name it had at that pass, so a rename after that pass does not show. The passes after the deletion carry only the key and never replace that name. A goal never recorded while it was in the catalog shows its key.

The goal_reached notice is informational. It does not refresh the conversation open in Chat and does not count toward the notices badge. Do not count goals from notices: a conversation keeps only its last 200. Conversation Insights reads its own records.

On this page