Configure Tags
Last updated: July 13, 2026
Tags let you automatically group supporters who share common traits or behavior. Once a tag is set up with entry rules, WeGive evaluates your supporters against those rules and applies the tag to everyone who qualifies — and, optionally, keeps that group current as supporters change over time. This article walks through every option on the Create Tag page so you can build tags that behave exactly the way you intend.
When to use a tag
Use a tag whenever you want a reusable, rule-based group of supporters. Common examples include first-time donors, lapsed donors, monthly recurring givers, event attendees, supporters in a specific region, or anyone above a giving threshold. Because tags are rule-driven, they stay accurate without manual list maintenance — unless you deliberately choose a one-time snapshot (see Static tag below).
Getting to the Create Tag page
From the Tags section of the dashboard, choose to create a new tag. You'll land on the Create Tag page, which is organized top to bottom: the tag's name, three behavior toggles (Remove supporters, Static tag, Sync to CRM), and the Entry rules builder where you define who gets tagged.
The top-right corner has three persistent controls:
Search fields — quickly find a specific field when building rules, useful when your organization has many custom fields.
Discard — abandons the tag without saving.
Review details — moves you to the confirmation step so you can verify everything before the tag is created.
Name
The Name field is required. Give the tag a clear, self-explanatory label such as "Monthly Donors" or "2026 Gala Attendees." This name is how the tag appears throughout the dashboard — in supporter profiles, segmentation, and reporting — so favor names your whole team will recognize.
Behavior toggles
Three toggles control how the tag behaves over time. They are independent of one another, and the right combination depends on whether you want an ongoing, self-maintaining group or a fixed snapshot.
Remove supporters
Remove supporters when they no longer match the rules — When enabled, supporters are removed automatically if they no longer qualify.
By default, once a supporter earns a tag they keep it. Turning this toggle on makes the tag fully dynamic in both directions: supporters are added when they start matching the rules and removed when they stop matching.
Use this when you want the tag to always reflect a current state. For example, a "Lapsed Donors" tag with this enabled will drop a supporter the moment they give again and no longer meet the lapsed criteria. Leave it off when membership should be cumulative — for instance, "Has Ever Attended an Event," where you never want someone removed once they've qualified.
This toggle has no effect when Static tag is enabled, since a static tag stops re-evaluating supporters entirely.
Static tag
Tag supporters once and never re-evaluate — Useful for one-time snapshots instead of ongoing automation.
A static tag captures the set of supporters who match the rules at the moment the tag runs, then freezes that membership. WeGive will not re-check supporters afterward, so no one is added or removed based on later activity.
Use a static tag when you need a point-in-time list — for example, "Donors as of End of FY2025" for a year-end report or mailing. Choose a dynamic (non-static) tag instead whenever you want the group to keep itself up to date.
Sync to CRM
Sync this tag and its members to the connected CRM — Requires the CRM integration's tag-sync toggle to also be enabled. Existing CRM records remain when this is turned off.
Enabling this pushes the tag and its members out to your connected CRM so the same grouping is available in both systems. Two things are worth noting:
This toggle only works if the CRM integration's own tag-sync setting is also enabled. If supporters aren't appearing in your CRM, confirm both switches are on.
Turning the toggle back off stops future syncing but does not delete records already written to the CRM — existing CRM data stays in place.
Entry rules
Define one or more segment-based entry rules for automated tagging.
Entry rules are the heart of the tag — they define who gets tagged. You can add multiple entry rules, and a supporter who matches any entry rule qualifies for the tag. Think of each entry rule as a separate doorway into the tag.
Click Add Entry Rule under "Tag Supporters" to create one. Each rule appears as a card (Entry Rule 1, Entry Rule 2, and so on) with a delete (trash) icon and a collapse/expand chevron in its header so you can tidy up the view while working.
Naming an entry rule
Each entry rule has its own Entry rule name field. Naming rules is optional for function but strongly recommended for clarity — for example, "High-value first gift" or "Northeast region" — especially when a tag uses several rules.
Audience Rule Groups
Configure group and rule logic to define this entry rule segment.
Within an entry rule, you build the actual logic using Audience Rule Groups. A new entry rule starts empty ("No groups yet. Add a group to start segmenting supporters."). Click Add Group to begin.
Two icons sit beside the Audience Rule Groups heading:
Gear (settings) — configure group/rule logic options for the segment.
Sparkle (AI assist) — get help generating the segment logic.
Adding rules to a group
Inside a group, each rule is a single condition built from three parts, evaluated left to right:
Select field — the supporter attribute to test (for example, total giving, last gift date, location, or a custom field). Use the Search fields box at the top of the page if you have many fields to sort through.
Select comparator — how to compare the field (for example, equals, greater than, before/after a date, contains, is set). The comparators available depend on the type of field selected.
Value — the value to compare against. Some comparators don't need one; in those cases the field shows "No value required" (for example, checking that a field simply has any value).
To add more conditions, click Add Rule inside the group. To remove the group entirely, click Remove Group. You can also click Add Group to create additional groups within the same entry rule.
How group and rule logic combines
Audience rule groups give you two layers of logic so you can express precise segments:
Rules within a group are combined with one logic operator (for example, all rules must be true, or any rule may be true).
Groups within an entry rule are combined with their own operator, letting you nest "must match this set, and also one of these other sets" style conditions.
Use the gear (settings) icon to control how rules and groups are joined. As a practical example, one group might require "Total giving is greater than $500" while a second group requires "Location is in the Northeast" — combined so a supporter must satisfy both groups to match the entry rule.
Audience preview
As you build, WeGive estimates the resulting audience and shows it beneath the rule builder. While calculating, you'll see "Calculating audience preview…"; once it finishes, it displays a live count, such as "Preview 0 people that are in your audience now." This is your real-time sanity check — if the count looks far too high, too low, or zero when you expect matches, revisit your fields, comparators, and group logic before saving.
Putting it together: a typical workflow
Enter a clear Name for the tag.
Decide on behavior: turn on Remove supporters for a self-cleaning dynamic group, Static tag for a frozen snapshot, and Sync to CRM if the group should also live in your CRM.
Click Add Entry Rule and give the rule a descriptive name.
Click Add Group, then add one or more rules (field → comparator → value).
Add more rules or groups as needed and use the gear icon to set how they combine.
Watch the audience preview count to confirm the rule captures the right people.
Add additional entry rules if you need alternative ways to qualify for the tag.
Click Review details, confirm everything, and create the tag.
Best practices
Name tags for the whole team, not just yourself. Use plain, descriptive names that say who is in the group and, where helpful, when — for example, "Monthly Donors (Active)" or "2026 Gala — Registered." Avoid abbreviations or internal shorthand that a new teammate won't recognize, since the name is what everyone sees in profiles, segments, and reports.
Match the behavior toggles to the tag's purpose before you build the rules. Decide up front whether you want a living group or a frozen list. Use a dynamic tag with Remove supporters on for "current state" groups (active recurring donors, currently lapsed), a dynamic tag with Remove supporters off for cumulative groups (anyone who has ever attended or given), and a Static tag only for true point-in-time snapshots like a year-end mailing list. Getting this right first prevents rebuilding later.
Be deliberate with "Remove supporters." It's powerful but easy to overlook. Turn it on only when dropping people who no longer qualify is genuinely what you want — and remember it does nothing on a static tag.
Treat static tags as one-time captures. Because they never re-evaluate, give them a date or context in the name (e.g., "Donors as of 12/31/2025") and create a fresh tag when you need an updated snapshot rather than expecting an old one to refresh.
Confirm both sides of CRM sync. Before relying on Sync to CRM, verify the CRM integration's own tag-sync toggle is enabled too. And remember that turning sync off later leaves existing CRM records in place — clean those up in the CRM directly if needed.
Name every entry rule. Even though it's optional, a descriptive rule name like "High-value first gift" makes a multi-rule tag readable and far easier to maintain months from now.
Use multiple entry rules for "OR across very different audiences." Since a supporter qualifies by matching any entry rule, separate, clearly named rules are cleaner than cramming unrelated conditions into one complex group. Reserve groups for the AND/OR logic within a single audience definition.
Start broad, then narrow. Build one rule, watch the preview count, then add conditions to tighten it. Adjusting against a live count is far more reliable than writing the full logic blind and hoping it's right.
Always sanity-check the audience preview before saving. A count that's wildly high, suspiciously low, or zero almost always signals a logic error — most often an "all conditions" group that should be "any," a wrong comparator, or a date/value typo.
Keep tags focused and avoid overlap. One tag should represent one clear idea. Many narrow, well-named tags are easier to use in segmentation than a few sprawling ones, and they reduce confusion about why a supporter is or isn't included.
Use the field search and AI assist to move faster. The Search fields box is the quickest way to locate the right attribute when you have many custom fields, and the sparkle (AI) icon can draft segment logic you then refine.
Review and prune periodically. As your data and programs evolve, revisit older tags to confirm their rules still reflect what you mean — and retire static tags that have served their purpose.
Tips and troubleshooting
No one is matching (preview shows 0). Check that your comparators and values are correct, and review whether your groups are set to require all conditions when any was intended.
Supporters aren't dropping off when expected. Confirm Remove supporters is enabled — without it, membership only grows.
The group never changes. Check whether Static tag is on; static tags don't re-evaluate.
Members aren't showing in the CRM. Verify both this tag's Sync to CRM toggle and the CRM integration's tag-sync setting are enabled.
Too many fields to scan. Use the Search fields box in the top-right to jump straight to the field you need.
Made a mistake mid-build. Use the trash icon on an entry rule or Remove Group within a group to clean up, or Discard to start over.