Member Filters
Member filters let you target a specific group of members based on labels, data fields, activity, and more. Saved filters can be reused across routines, reports, and campaigns.
Filter by the Member's local time
In Calendar, choose Member local weekday, Member local hour, or Member local time. For example, combine Member local weekday is not Friday with Member local hour ≥ 10 and your label conditions. The same controls are available in a Journey branch's inline Member Match editor; no shared filter name is needed for a condition used only on that branch.
The Member's timezone is used when available. Otherwise the workspace timezone is used, or UTC if the workspace has none. A time range includes both displayed minutes. For a range crossing midnight, use an OR group, such as Member local time ≥ 22:00 OR Member local time < 06:00.
These conditions are checked when the Journey evaluates the branch. They do not schedule a future check at an exact minute; use Journey active hours to restrict when the Journey processes members. Counts in the UI show the latest requested sample, not a live clock.
Steps
1. Navigate to the Members view
Go to the Members page in your workspace.
2. Open the filter editor
Above the member list you will see an input-styled row showing either a syntax-highlighted sentence that summarises the active filter conditions, or the placeholder text No conditions when no conditions have been set. Click anywhere in that row (or the Edit button on the right) to expand the inline query builder below it.
3. Build your filter conditions
With the editor expanded, add and configure conditions using the predicate builder. Each condition row lets you:
- Field: pick a field from the category palette (see the table below for available categories).
- Operator: choose how to match (e.g. "contains," "any of," "greater than," "does not exist").
- Value: enter or select the value to match against (text input, multi-select dropdown, date picker, etc., depending on the field type).
All conditions are combined with AND logic — a member must match every condition to be included.
The sentence preview at the top of the editor updates live as you work. When a condition is incomplete (e.g. operator selected but no value yet), the row shows a red ring; the filter is not sent to the server until all conditions are valid.
Available field categories
| Category | Fields |
|---|---|
| Profile | Name, External ID, UUID, Date of birth, Timezone, Age, Member since (created), Member type, Test member, Role, Terms accepted, Can log in, Labels |
| Contact | Email, Phone, Phone type |
| Notifications | SMS notifications enabled, Email notifications enabled, Voice notifications enabled |
| Communications | Latest SMS delivery failed, Has forwarded call, Needs response, Message content |
| Workflows | In workflow (see operators below) |
| Journeys | Enrolled in journey, current journey step, completed journey step, journey step status, and journey enrollment (status on the same enrollment) |
| Calendar | Member local weekday, hour and time; calendar events (via the calendar relation) |
| Member Fields | Custom member field keys defined in your workspace |
| Forms | Fields from each Form (DataType) defined in your workspace |
Fields such as Labels, Role, Workflow and Journey are chosen from a list of what exists in your workspace. If the workspace has none yet, the picker reads None yet, and opening it explains why; create some (for example, under Labels) and they appear in the list.
Workflow filter operators
The In workflow field has several operators that differ in an important way — what counts as a member being "in" a workflow. This matters most when you use a filter to drive a routine that calls or messages members, because the routine re-evaluates the filter on every run:
| Operator | Includes members who… | Use it for |
|---|---|---|
| Entered any / Entered all | have ever been in the selected workflow(s) | reporting on participation |
| Not currently in | have no active assignment right now (a completed or canceled one does not exclude them) | recurring routines that should reach a member again after a prior run finished |
| Never entered | have never been in the workflow at all (any past attempt — completed or canceled — keeps them excluded) | one-shot campaigns where each member should be contacted exactly once |
| Date condition → not entered in last N days | have not entered the workflow within the last N days (a rolling window — eligible again after it passes) | rate-limited outreach, e.g. "at most one attempt per 24 hours" |
Important for one-shot calling/SMS campaigns: use Never entered, not Not currently in. A call or text workflow often finishes within minutes (e.g. on a busy or no-answer result), so with Not currently in the member becomes eligible again and the routine will contact them repeatedly on each run. Never entered keeps them excluded once they have entered.
Journey filter fields
Use the Journeys group (next to Workflows) when you want a reusable member list of who is in a program, or who is on / has finished a step — the same questions the journey's Members tab answers, saved as a filter for routines and QA.
| Field | Matches members who… |
|---|---|
| Enrolled in journey | have an active enrollment in the selected journey(s). Canceled and completed enrollments do not match. Is empty means not actively enrolled in any journey. |
| Current journey step | are sitting on that step right now (eligible or in progress, or the same fallback the Members tab shows when they are blocked). |
| Completed journey step | have completed that step, even if they have since moved on or finished the journey. |
| Journey step status | have a step in that status (pending, eligible, in progress, completed, …) on an active enrollment. |
| Journey enrollment (card) | match journey and enrollment status on the same enrollment — use this for "canceled from journey X". |
Pick journeys and steps from the named chooser, not by id. Saved filters that a journey uses for auto-enroll are unchanged; you can now also build filters that describe journey progress.
Grouping members by an External ID pattern
If your external system encodes something meaningful in the member's External ID — a site or clinic code prefix, a batch, a program — you can group members by it without adding a label to each one:
- starts with matches a prefix, which is usually what a code at the front of the identifier calls for.
- contains matches the text anywhere in the identifier.
Both ignore case. Use the search box above the list instead when you are looking for one specific person, since it searches name, email and phone as well as External ID; the filter searches External ID only, so it is the one to use when you want the whole group. Search strings of one or two characters are much slower than three or more.
Timezone and “does not exist”
Timezone is the IANA zone stored on the member (for example
America/New_York). Pick it from the list — you do not have to type the id.
Does not exist matches members whose timezone is unset (empty or missing),
which is the same population that journeys treat as the workspace timezone.
The same does not exist / exists operators are available on other
nullable member properties and on custom Member fields (including
Salesforce-backed keys): “does not exist” means there is no value — no
member_fields row, or a blank one.
4. Review the filtered list
The member list updates in real time as you add conditions. Check the member count and spot-check a few entries to confirm the filter captures the audience you intend. The sentence preview at the top of the editor shows a readable summary of your current conditions.
5. Save the filter
Click Save in the filter editor row. An inline name editor will appear.
6. Name the filter
Enter a descriptive name for the filter (e.g., "Enrolled — Diabetes Management" or "Active patients without recent activity"). Press Enter or click the checkmark to confirm.
The filter is now saved and available for use in routines and other features.
Converting a legacy rule-based filter
Older filters may use the classic rule builder (a separate panel with individual rule rows) instead of the inline query builder. When a legacy filter is active, the toolbar shows a Convert to new query format button (arrows icon).
Clicking it runs a dry-run conversion on the server and opens a preview of the translated query sentence in the inline editor. You can:
- Review the converted conditions before committing — the member list updates live so you can confirm the result matches your expectations.
- Save to permanently replace the legacy rules with the new query format.
- Cancel to discard the preview and return to the legacy rule editor — the original rules are not changed until you save.
The conversion is reversible at the preview stage; once saved, the filter is stored in the new format only.
Managing Saved Filters
- Load a saved filter: Click the Select Filter dropdown to see all saved filters. Click one to apply it.
- Pin a filter: Click the star icon next to a filter to pin it for quick access. Pinned filters appear at the top of the dropdown.
- Edit a filter: Load a saved filter, click Edit in the filter editor row, modify the conditions, and click Save to update it. Click Cancel to discard unsaved changes.
- Delete a filter: Click the trash icon next to a saved filter and confirm deletion.
Tips
- Filters resolve dynamically — the member list is evaluated at the time of use (e.g., when a routine fires), not when the filter is saved.
- Test members, including the callers that workflow test runs create, are left out of everything a filter selects unless a condition asks for them: a Test member condition, or a Member type condition that includes Test.
- Use the member count displayed in the filter results to sanity-check your criteria before using the filter in a campaign.
- Combine Labels with Latest SMS delivery failed to target members who match a program AND haven't received recent messages successfully.