Module · Working with the CRM

Contact Summary

Lesson 2 of 21 · 6 min

Before a call, someone opens the contact record and starts scrolling. Three deals, two of them closed. Eleven activities. A note from four months ago that turns out to be the important one. Five minutes later they have the picture, and the picture was always there — it was just spread across six tabs.

Contact Summary does that reading. Point it at a contact, tell it which related records count, and it pulls them together and writes a summary of the relationship. It is the one CRM action node that produces prose rather than a record: what comes back is a brief, plus a list of things worth doing next.

That makes it useful in two places. On a button, so a rep gets the brief on demand. And ahead of anything automated that needs context — a follow-up email, an agent about to answer a question, a task assigned to someone who has never spoken to this person.

Five fields, four of them nested

The whole node. Everything except the identifier is a group of settings rather than a single value.

Field	What it holds
`contact_identifier`	Contact ID, email, or phone number to summarize Defaults to `{{contact.id}}`.
`contact_fields`	Configure which contact fields to include
`entity_inclusion`	Configure which related entities to include
`summary_settings`	AI summary configuration
`time_filters`	Time-based filtering for historical data

contact_identifier

What it holds: Contact ID, email, or phone number to summarize Defaults to {{contact.id}}.

contact_fields

What it holds: Configure which contact fields to include

entity_inclusion

What it holds: Configure which related entities to include

summary_settings

What it holds: AI summary configuration

time_filters

What it holds: Time-based filtering for historical data

Only contact_identifier is required, and it takes an id, an email address or a phone number — whichever you happen to have upstream. Everything else has defaults that are already sensible, which means the node works the moment you drop it in. The nested groups are how you make it cheaper or sharper.

entity_inclusion — which related records to gather, and how many of each. Deals, tasks, notes and activities are on by default; companies are off.
summary_settings — how long the summary is, and whether to add insights and suggested next actions. It can also write the result straight back onto a field on the contact.
time_filters — how far back to look. The default is the last 90 days, weighted toward recent interactions.
contact_fields — which of the contact's own columns to feed in. Standard and custom fields are both included by default.

A worked example

A button on the contact record. A rep presses it, the node reads 90 days of history, and the brief is filed as a note on the contact so it is there for whoever opens the record next.

Brief me on this contact

Click the middle node to see what it gathers and how the summary is shaped.

Scroll for all 3 steps →

The inclusion block is where the thinking goes. Closed deals are on here, because history is the point — a lost deal from last year is exactly the context a rep wants before dialling. Companies are off, because this contact's employer is not what the call is about. Every record type has a cap, and the caps are low on purpose: a summary built from five deals and ten activities is a better brief than one built from everything, and it costs less to produce.

The last node writes the brief somewhere a human will find it. That is the part people leave out, and a summary nobody reads is just an expensive API call.

What comes back

There is no plain `summary` field. It is `ai_summary`.

Reference	What you get
`{{alias.ai_summary}}`	The brief itself, as prose. This is the one you put in a note, an email or a prompt.
`{{alias.insights}}`	What the model noticed — patterns in how this contact behaves.
`{{alias.next_actions}}`	Suggested next steps. Treat as a prompt for a human, not a plan to execute.
`{{alias.related_data.deals}}` · `{{alias.related_data.companies}}`	The records it gathered, structured. Useful when you want the data as well as the prose.
`{{alias.summary_metadata.total_interactions}}`	How much history the summary was actually built from. Worth branching on — see below.

{{alias.ai_summary}}

What you get: The brief itself, as prose. This is the one you put in a note, an email or a prompt.

{{alias.insights}}

What you get: What the model noticed — patterns in how this contact behaves.

{{alias.next_actions}}

What you get: Suggested next steps. Treat as a prompt for a human, not a plan to execute.

{{alias.related_data.deals}} · {{alias.related_data.companies}}

What you get: The records it gathered, structured. Useful when you want the data as well as the prose.

{{alias.summary_metadata.total_interactions}}

What you get: How much history the summary was actually built from. Worth branching on — see below.

The metadata is more useful than it looks. summary_metadata.total_interactions tells you how much there was to summarise, and a contact with two interactions produces a brief that says very little at some expense. A Condition on that count, sending thin contacts down a different path, is the cheapest improvement you can make to any workflow built on this node.

What breaks

The short-summary option is spelled brie, not brief. That is the value in the node's enum and the value its prompt builder looks up, so brie is what works. Passing brief does not error — it misses the lookup and falls back to detailed, so you get a longer summary than you asked for and pay for the extra tokens. The node's own documented example passes brief. Verified against the node source 2026-08-01.

The second failure is quieter and costs more. Every record type you enable is data fetched and sent to a model, so turning everything on with high caps produces a long summary, slowly, on every run. The defaults exist because they are the useful subset. Raise a cap when a summary is visibly missing something, not in advance.

The third is about trust. next_actions is generated from what the model saw in the history — it is a suggestion, and it is confident in the same tone whether it is right or not. Putting it in front of a person is fine. Wiring it into something that acts is not, unless a person approves it first.

This node or the CRM Manager?

Use	When
`contact_summary`	You want the relationship explained. The output is prose meant for a person or a prompt.
`crm_manager`	You want the records themselves. The output is data meant for another node.

contact_summary

When: You want the relationship explained. The output is prose meant for a person or a prompt.

crm_manager

When: You want the records themselves. The output is data meant for another node.

They compose well. A CRM Manager search finds the twenty contacts that went quiet; a Loop runs Contact Summary over each; the briefs land as notes for whoever picks them up. Neither node does that alone.

Try it

Add a Contact Summary after any node that gives you a contact, and put that contact's id or email in contact_identifier. Leave every other setting alone and run it.
Read {{alias.ai_summary}} in the execution log, then read {{alias.summary_metadata.total_interactions}} and see how much history it had to work with.
Set summary_length to brie and run it again — the brief should drop to two or three sentences. Now spell it brief and watch it come back long.
Turn on closed deals in entity_inclusion for a contact who has one, and compare the summaries. This is the setting that most changes what the brief says.

Next: Segment Manager — moving contacts in and out of segments, which is how the summary you just wrote reaches the right list.