Skip to main content
Custom fields let you extend any record in WeGive — donors, transactions, campaigns, and more — with your own data. Use them to track information that matters to your organization but isn’t part of WeGive out of the box, like a donor’s volunteer status, a transaction’s grant cycle, or the lifetime giving total for a household. This article covers what custom fields are, how to create them, where they show up across WeGive, and the most common ways nonprofits use them.

​
What is a custom field?

A custom field is attached to one object (for example, Donor or Campaign) and adds a new piece of data to every record of that type. You decide the name, the data type, and what record it lives on. A custom field lives on one object only and can’t be moved later, so choosing the right one up front matters. WeGive then makes that field available everywhere you’d expect it: profiles, filters, segments, exports, merge tags in emails, and integrations. There are two kinds of custom fields:
  • A Static field holds a value you set, import, or collect from a form — text, a number, a date, or a yes/no flag. WeGive doesn’t change it; you control it. Examples: a donor’s preferred name, a transaction’s check number, a household’s anniversary date.
  • A Computed field calculates its value automatically from related records. WeGive does the math for you and keeps it up to date as the underlying data changes — you don’t enter these values by hand. Examples: a donor’s lifetime giving total, the date of a donor’s most recent gift, the count of registrations for an event.

​
Records you can add custom fields to

Custom fields can be attached to any of these record types:
  • Donors — individual and company supporters
  • Households — families and groups of donors
  • Transactions — individual payments and donations
  • Recurring Donations (Scheduled Donations) — scheduled/recurring giving plans
  • Pledges — committed future gifts
  • Campaigns — your fundraising campaigns
  • Events (Campaign Events) — campaign events
  • Event Registrations (Campaign Event Registrations) — registrations for those events
  • Fundraisers — peer-to-peer fundraising pages
  • Campaign Fundraisers — fundraiser pages within a campaign
  • Designations (Funds) — the funds donations are allocated to
This choice determines which relations are available later for computed fields, so set it first.

​
Who can manage custom fields

Creating, editing, and deleting custom fields is restricted to Admin and Developer roles. Custom fields are scoped to your organization, so anything you create is only visible inside your WeGive account. Other roles can still see and use custom field values where they appear — on a donor profile, in a segment, as a merge variable — they just can’t create or modify the fields themselves.

​
Where to find custom fields

You’ll need access to Settings → Custom Fields in Dashboard v2. This page lists every custom field in your organization and is where you go to create, edit, or remove them.

​
Creating a custom field, step by step

  1. Go to Custom Fields and click Create Custom Field.
  2. Object (required) — Choose the record type this field belongs to (see the full list above — the exact options available depend on your plan and configuration). This choice determines which relations are available later for computed fields, so set it first.
  3. Name (required) — Give the field a clear, human-readable name (for example, Region or Lifetime Gift Count). The name also generates the field’s reference name used in rules and exports, so make it descriptive and stable — see the API name format below.
  4. Type (required) — Choose Static or Computed. The rest of the form changes based on this choice.
  5. Fill in the remaining fields for your chosen type (see Static fields / Computed fields below).
  6. Click Review details, confirm everything looks right, and save.
After you save, WeGive initializes the field across existing records in the background. For a large object (like Donor), values may take a little time to populate on every record.

​
Static fields

Choose Static when you want a field you fill in, import, or collect from a form yourself. After selecting Static, set the Configuration Type (labeled “Select static field type”), which determines what kind of value the field accepts:

​
Default Value (optional)

The Default Value is what every record starts with before anyone enters a value. For a Boolean field, leaving the toggle alone stores false by default rather than an empty value — so a new Boolean field reads as “no” until you flip it. Leave Default Value blank if you’d rather records start empty.

​
Number formatting options (optional)

For numeric values, four optional fields control how the value is displayed (they don’t change the stored number):
  • Prefix — text placed before the number, such as $.
  • Suffix — text placed after the number, such as pts or %.
  • Multiply By — a multiplier applied before display. For example, a stored value of 0.25 with a multiplier of 100 displays as 25. Useful when source data is in cents but you want to display dollars.
  • Precision — the number of decimal places to show, using a comma as the thousands separator. Use a non-negative whole number (0, 1, 2, …). With precision 2, 1234.5 displays as 1,234.50.
The display order is: multiply → round to precision → add prefix and suffix. So a value of 12.5 with multiply-by 1, precision 2, prefix $, suffix USD shows as $12.50 USD. These formatting options apply only to numeric values — they’re ignored for Text, Date, and Boolean fields.

​
Computed fields

Choose Computed when you want WeGive to calculate the value automatically from related records. A computed field is built from three parts:
  1. Relation (required) — the related records to look at. The available relations depend on the Object you picked at the top. For example, a Donor can roll up its donations, fundraisers, pledges, or scheduled donations; a Campaign Event can roll up its registrations. If you see “No results found,” it usually means you haven’t selected an Object yet (or that object has no roll-up relations available) — set the Object first.
  2. Aggregation (how to summarize the related records) — once a relation is chosen, you tell WeGive how to combine those records:
  3. Which attribute to summarize (required for Sum, Average, Minimum, Maximum) — the field to calculate on (for example, the donation amount, or created_at for a date). Count, Exists, and Doesn’t exist don’t need an attribute.
The aggregation method determines the field’s value type automatically: Count, Sum, and Average produce a number; Minimum and Maximum produce a date when the attribute is a date (otherwise a number); Exists and Doesn’t exist produce a yes/no (Boolean) value.

​
Filters (optional)

Filters narrow which related records are counted. They’re configured from the relation you selected — so until you choose a relation, you’ll see “Select a relation to configure filters.” Use filters to compute things like “number of successful donations” or “total raised this year” rather than across all records. Use Add filter for a single condition or Advanced filters to combine several.

​
When computed values update

Computed fields recalculate automatically as the underlying records change — for example, when a donor makes a new donation, their “donation count” field updates. You don’t enter these values by hand. Note that the prefix, suffix, multiply-by, and precision formatting options apply to numeric computed results too, just as they do for static numbers. Computed fields are read-only — you can’t type a value into a computed field on a record; change the underlying data (or the field’s filters) instead.

​
Editing and deleting custom fields

From the Custom Fields page, click any field to edit its name, formatting, or default value. To delete a field, use the delete action in the same view. Deleting a field removes it everywhere it’s used, including segments, journeys, tag rules, and merge variables — double-check before removing one that’s been around for a while.

​
Where custom field values show up

  • Record detail views — the field appears on every record for its object. Static fields are editable inline; computed fields show the calculated value as read-only.
  • Segments and filters — build audience segments and filtered table views using custom field values as criteria, e.g., “donors whose lifetime giving total is over $1,000.”
  • Tag rules — use custom fields as inputs to your tag rules so donors are automatically tagged based on the data you track.
  • Emails and messages — custom fields are available as merge variables, so you can personalize messages with values like a donor’s preferred name or their last gift amount.
  • Journeys — use custom field criteria to trigger automated journeys or branch journey logic based on the value of a field.
  • Reports and exports — custom field values are included in any export you run and can be added as columns in reports.
  • Custom questions — custom questions on checkouts, registration forms, and other forms can be configured to save the donor’s answer to a custom field.
  • CRM integrations (Salesforce and others) — when a custom field value changes, WeGive syncs the parent record to your connected CRM, so the value can flow downstream where supported.

​
API / reference name format

Each field gets a stable reference name in the form CF_<id>_<field_name> (for example, CF_42_region). Use this when building audience segments, automation rules, or merge variables, and when mapping the field on the CRM side — if your org has a Salesforce integration, make sure your Salesforce admin knows the new field exists so they can map it.

​
Common use cases

Some of the most common custom fields nonprofits set up:
  • Donor lifetime giving — A computed Sum on the Donor record over transactions.amount. Powers segments, recognition tiers, and merge tags in stewardship emails.
  • Last gift date — A computed Max on the Donor record over transactions.created_at. Useful for lapsed-donor segments and re-engagement journeys.
  • First gift date — A computed Min on the Donor record over transactions.created_at. Useful for new-donor onboarding journeys.
  • Number of gifts — A computed Count on the Donor record over transactions.id. Good for “ever donated” segments.
  • Volunteer status — A static Boolean on the Donor record.
  • Grant cycle — A static Text field on the Transaction record. Tracks which grant cycle a gift belongs to for reporting.
  • Anniversary date — A static Date field on the Household record for sending an annual thank-you.
  • Event headcount — A computed Count on the Event record over registrations.id. Live attendance number on the event itself.

​
Best practices

  • Pick the object deliberately. A custom field belongs to one object and can’t be reassigned. If you want the same concept on two objects (e.g., a tag on both Donor and Campaign), you’ll create one field on each.
  • Use Computed instead of manual upkeep. If a value can be derived from existing records — counts, totals, first/last dates — make it Computed so it stays accurate without anyone updating it. Reserve Static for information only a human knows.
  • Add filters to make computed fields meaningful. An unfiltered “donation count” includes failed and refunded transactions. Filter to successful donations (and a date range if relevant) so the number means what people assume it means.
  • Name for clarity and stability. The name drives the reference name used in rules, exports, and merge tags across segments, journeys, tag rules, and your CRM. Choose something descriptive and consistent (donor_lifetime_giving rather than LTV) — you won’t want to rename it later.
  • Set sensible defaults for Static fields. A default keeps records consistent from day one — especially for Boolean fields, where a default of “no” is usually clearer than an empty value.
  • Keep formatting in the field, not the data. Store the raw number and use Prefix/Suffix/Precision for display. That keeps the underlying value clean for math, sorting, and exports.
  • Don’t over-create. Every field appears on every record and adds clutter. Create fields you’ll actually use in segments, reports, or integrations, and retire ones you don’t.

​
Tips and gotchas

  • “No results found” under Relation almost always means no Object is selected yet, or the selected object has no available roll-up relations. Set the Object at the top first.
  • Formatting options only affect numbers. Prefix, Suffix, Multiply By, and Precision are ignored for Text, Date, and Boolean fields.
  • Multiply By is for unit conversion/display, not storage. It changes what’s shown, not what’s stored — handy for showing a stored decimal as a percentage, or cents as dollars.
  • Precision must be a non-negative whole number. Use 0 for whole numbers; decimals or negatives aren’t valid.
  • New fields populate in the background. On large objects, give existing records a moment to fill in after you save — values won’t all appear instantly.
  • A field’s value type is fixed by its setup. For computed fields the aggregation method (and attribute) sets whether the result is a number, date, or yes/no. If you need a different type, you’ll create a new field rather than convert the existing one.
  • Computed fields are read-only. You can’t override a computed field’s value on a single record. If you need to manually adjust it, you probably want a static field instead.
  • Deleting is permanent. Removing a custom field also removes any references to it in segments, journeys, tag rules, and merge variables. Audit those before deleting.
  • Permissions. If a teammate can’t see Custom Fields, check their role. Only Admin and Developer roles can manage them.

​
Quick reference

​
Need help?

If you’re not sure what record type a field should attach to, or whether to use a static or computed field for what you’re trying to track, reach out to your WeGive contact and we’ll help you set it up.