The two ways to build a Segment, how each one's membership logic behaves, and where they still differ in validation and naming.

Overview

A Segment is a named group of users. Intempt gives you two different ways to build one: selecting rows manually on the Users list, or saving a filter, sort, and column combination as a reusable view. Each path produces a different kind of membership logic, with different validation rules and different editing rights. This reference covers exactly how the two compare, so you know what you're building before you rely on it elsewhere in the product.

📘 Good to know

For a walkthrough of manual-selection segment creation, see Creating a segment. For the filter-based path, see Lists.

Two ways to build a segment

Aspect	Manual selection	Filter-based (saved view)
Where you start	Select rows on the Users list, then click "Create segment"	Apply a filter, sort, or column change on the Users or Accounts table
What it creates	A Segment: a fixed list of the rows you selected	A saved view: a reusable filter, sort, and column combination
Name uniqueness	Checked. A duplicate name blocks creation.	Not checked. The same name can be reused, even against an existing Segment's name, with no warning.
Membership	Static, frozen at the moment of creation	Dynamic, reapplied every time the view is selected
Editable later	No. Nothing renames, updates, or removes it once created.	Yes. Reselect it, change it, and save over the same entry, or save it as a new one.
Available on Accounts	No. No equivalent selection action exists on the Accounts list.	Yes. The same mechanics work on both the Users and Accounts tables.

Segment fields

Field	Values	Notes
Name	Any text	Uniqueness is only checked for manual-selection segments (see the validation table below).
Object type	User or Account	Every current creation path produces User-type segments only. No screen creates an Account-type segment, so any Account-scoped "Score segment" picker can only offer "All accounts."
Membership	Fixed at creation	The list of ids is locked in when the segment is created. No new users are ever added automatically. If a member is later deleted from your project, the segment's count reflects that, but the segment itself still exists indefinitely, with no way to remove or clean it up.

Manual-selection validation

The "Create segment" entry point only appears once you've selected at least one row on the Users list. The banner above the name field tells you how many users will be added, or asks you to select at least one if none are selected yet.

Name field state	What happens	Message shown
Empty	"Create" is disabled	"Required value"
Typing, while the name is checked	"Create" is disabled	"Checking availability..."
Name already used	"Create" is disabled	"Duplicate value"
Name available	"Create" is enabled	"Name is available"

"Create" is also disabled while a create request is already in progress (the button reads "Creating...") or if no rows are currently selected.

Filter-based save behavior

The filter-based path has no dedicated dialog. It works through the same toolbar you use to filter, sort, and choose columns on the Users or Accounts table:

With no saved view currently selected, changing a filter, sort, or column puts the toolbar into an unsaved state with a single "Save as new list" button.
Clicking it opens a side panel to name and save the view. Leaving the name blank disables the save button; there's no separate error message beyond that.
Saving with a name that matches another saved view, or even an existing Segment's name, succeeds with no warning. Name uniqueness isn't enforced on this path at all.
On save, the new view appears immediately in the header switcher next to the page title, with a live member count. No page reload is needed.
Selecting "All users" resets the table to its default state. Reselecting a saved view reapplies its exact filter, sort, and columns.
Once a saved view is selected and you change it again, the toolbar switches to a "Save" / "Save as new list" choice: "Save" overwrites the same view; "Save as new list" creates a separate one and leaves the original untouched.
Canceling a change reverts the table to the last-saved state for the selected view, or to defaults if no view is selected.
No saved view can be renamed or deleted, in the header switcher or anywhere else.

This behavior is identical on both the Users and Accounts tables. A view saved on one table doesn't show up on the other's switcher.

Current terminology

As of this writing, the filter-based path still uses different words for the same idea across its own flow:

Toolbar button: "Save as new list"
Save panel: header "Save as new view," button "Save view"
Confirmation: View '{name}' created
Header switcher search box: "Search segments" (already using "segment")

Intempt's product direction is to converge all of this on "Segment," matching the manual-selection flow's wording, on both Users and Accounts. Until that ships, expect "list" and "view" in the copy above, not "segment."

Use cases

Score an RFM, Qualify, Likelihood, or Next Best Product attribute against a specific group of users instead of your whole base, using its "Score users in segment" field.
Target an Experience variant at a specific group of users with the "Specific users" audience option.
Trigger or exit a Journey based on whether a user belongs to a segment.
Freeze a one-time snapshot of users, for example everyone who converted during a specific campaign, by selecting rows manually.
Build a reusable, named view from a filter combination, for example "Enterprise-tier trial users," so you don't rebuild the same filter every time you need it.
Update a saved view's definition as your criteria change, by saving over the same entry instead of creating a new one each time.
Check whether a "segment" a picker shows you is actually a static Segment or a filter-based saved view, since both can appear in the same dropdown.

Known limits

No screen creates an Account-type segment. Any Account-scoped picker can only offer "All accounts."
A Segment can't be renamed, edited, or deleted once created.
A Segment's membership never recalculates. There's no way to build a segment that updates automatically as new users start matching its criteria. The count only ever goes down, if a member is later deleted from your project.
A filter-based saved view has no duplicate-name check at all, unlike a Segment.
The wording gap described above ("list"/"view" vs. "segment") is a known, tracked inconsistency, not a sign that the two paths behave differently than described here.

Segment Conditions & Logic Reference