Skip to content
Expedify
Start free
5 min

Segment Manager

Segments are how the rest of Expedify finds a group of people. This node is how a workflow puts someone in one, takes them out, or moves them between two — and how it asks whether they are already there.

A segment is a named group of contacts. Campaigns send to one. Dashboards count one. A Segment trigger fires when someone joins one. So the question of who is in which segment is not administrative housekeeping — it is what decides who hears from you and what they hear.

Most of the time segments fill themselves from their own filter rules. The Segment Manager is for the times they should not: a contact who qualifies during a call, a trial that converts, a lead who asked to stop hearing from you. Those are decisions your workflow makes, and this node is how it writes them down.

One required field, and six that depend on it

Only `operation` is required. Which of the others you need is decided by which operation you picked.

operation

What it holds
Operation to perform on segment membership One of: add_to_segment · remove_from_segment · move_between_segments · check_membership · get_segments · bulk_add · bulk_remove Defaults to add_to_segment.

contact_source

What it holds
Where to get contact ID from: 'input' from previous node, 'config' from static value One of: input · config Defaults to input.

contact_id

What it holds
Contact ID (supports template variables like {{trigger.contact_id}})

segment_id

What it holds
Target segment ID

source_segment_id

What it holds
Source segment ID for move operation

target_segment_id

What it holds
Target segment ID for move operation

That last point is the whole configuration story, and the schema cannot tell you it. segment_id is what an add or a remove needs; a move ignores it and wants source_segment_id and target_segment_id instead. Fill in the wrong pair and the node has nothing to act on.

Seven operations. The plural fields go with the bulk ones.

add_to_segment

What it needs
contact_id + segment_id
What it does
Puts one contact in one segment.

remove_from_segment

What it needs
contact_id + segment_id
What it does
Takes them out of it.

move_between_segments

What it needs
contact_id + source_segment_id + target_segment_id
What it does
Out of one, into the other, as one step.

check_membership

What it needs
contact_id + segment_id
What it does
Asks a yes/no question. Changes nothing.

get_segments

What it needs
contact_id
What it does
Lists every segment this contact is in.

bulk_add / bulk_remove

What it needs
contact_ids + segment_id
What it does
The same, for a list of contacts.

contact_source decides where the contact comes from: input takes it from the node upstream, config uses a value you typed. Leave it on input for anything triggered by an event, which is nearly everything.

A worked example

A contact record is updated. If the update was the one that matters — they qualified — they belong in Hot Leads and no longer belong in Trial. One node does both halves.

Out of Trial, into Hot Leads

A move needs a source and a target, and no segment_id at all.

Segments are addressed by id, not by name. Those two ids are Trial and Hot Leads in the org this was built in, and a workflow copied to another org needs its own. That is worth knowing before you copy a workflow between environments and wonder why nobody moves.

Doing this as a move rather than a remove followed by an add is not just tidier. Two nodes means a moment where the contact is in neither segment, and if anything between them fails the contact stays in neither. The move is one step, so there is no gap to fall into.

What comes back

This node nests its output under data. That is a difference from the CRM Manager two lessons back, and it is the kind of thing you discover by way of an empty value rather than an error.

{{alias.data.is_member}}

What you get
True or false, after check_membership. The one you branch on.

{{alias.data.segments}}

What you get
Every segment the contact belongs to, after get_segments.

{{alias.data.segment_name}}

What you get
The segment acted on, by name — useful in a message or a log line.

{{alias.data.total_added}} · {{alias.data.total_removed}}

What you get
Counts, after a bulk operation. Check them; a bulk call that matched nothing still succeeds.

What breaks

Membership is not the same as a campaign send. Adding someone to a segment that a campaign targets can put a message in front of them. Removing them from a suppression segment can do the same. When a workflow writes membership automatically, it is worth tracing which campaigns read that segment before turning it on — the node is doing exactly what you asked, and the consequence is one step further away than it looks.

A bulk operation that matched nothing looks like a success. There is no error for adding zero contacts. data.total_added is the only thing that tells you, so read it rather than assuming the run did work.

A segment with its own filter rules will re-evaluate. If a segment's rules say who belongs in it, adding someone by hand who does not match those rules may not stick. Reach for this node on segments that are meant to be written to, and let rule-driven segments fill themselves.

This node, or the segment's own rules?

The segment's filter rules

When
Membership follows from data you already store — lead status, last activity, deal stage. The segment maintains itself and nobody has to remember to run anything.

segment_manager

When
Membership follows from something that happened: a call went well, a form was submitted, a person decided. There is no field to filter on, because the decision is the event.

The mistake is reaching for the node first. If you can write the rule, write the rule — a segment that maintains itself cannot drift out of date, and a workflow that maintains one can, quietly, the first time it fails.

Try it

  1. Create two segments in the CRM. Add a Segment Manager, set the operation to add_to_segment, and give it a contact id and one of the segment ids. Run it and check the segment.
  2. Change it to check_membership and read {{alias.data.is_member}} in the execution log. Then check a contact who is not a member and read it again.
  3. Switch to move_between_segments, fill in a source and a target, and leave segment_id filled in too. Notice that it is ignored — the operation decides which fields are read.
  4. Now run the move for a contact who is not in the source segment, and see what the node does with that. It is the case a real workflow hits most often.

Next: Smart Charts — the last node in this module, and the only one whose output is a picture.

Try this in Expedify →

Related lessons

12 min read

Base rates — what a piece of evidence is actually worth

A face-recognition system that is 99.9% accurate and almost entirely wrong, and a number that sent an innocent woman to prison. Both are the same arithmetic, and it is the arithmetic that decides what any piece of evidence is worth.

Read
10 min read

Confirmation and survivorship — what you never looked for

Two questions about evidence you did not go looking for. One is a rule you have to discover, and one is a pattern in five famous people — and in both, the thing that would have told you the truth is the thing nobody checks.

Read
14 min read

Loss aversion, sunk cost and regression — what it costs you

Four questions you answer about yourself rather than about a scenario, and your own answers are the finding. Then the pattern that makes praise look useless and criticism look like it works, whatever you actually do.

Read