Configure Custom Fields (Dashboard v2)

Custom fields let you store and calculate information on WeGive records that isn't captured by a standard field — things like a region code on a donor, a board-member flag, or the total amount a donor has given through a specific relationship. This guide walks through everything on the Create Custom Field screen, explains what each option does, and shares best practices so your fields stay clean and useful over time.

What a custom field is

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. There are two kinds:

• A Static field holds a value you set or import yourself — text, a number, a date, or a yes/no flag. WeGive doesn't change it; you control it.

• A Computed field calculates its value automatically from related records. For example, "number of donations" or "total registrations for this event." WeGive recalculates it as the underlying data changes.

Once created, your custom field appears on every record for that object and can be referenced throughout WeGive — in record detail views, exports, and in rules and segments via the field's reference name.

Before you start

• You'll need access to Settings → Custom Fields in Dashboard v2.

• Decide which object the field belongs to. A custom field lives on one object only and can't be moved later, so choosing the right one up front matters.

• Decide whether the value is something you'll enter/import yourself (Static) or something WeGive should calculate (Computed).

Create 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. Options include Donor, Scheduled Donation, Campaign Event Registration, Campaign, Campaign Event, and Fundraiser. (The exact list depends 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.

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.

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 or import 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.

• 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. How to summarize the related records — once a relation is chosen, you tell WeGive how to combine those records. The common options are:

   • Count — how many related records exist (e.g., number of donations).

   • Sum — add up a chosen value across the records (e.g., total amount).

   • Average — the average of a chosen value.

   • Minimum / Maximum — the lowest or highest value (often used with dates, e.g., first or most recent gift date).

   • Exists / Doesn't exist — a yes/no flag for whether any matching record exists (e.g., "has ever donated").

3. Which attribute to summarize — for Sum, Average, Minimum, and Maximum you also pick the field to calculate on (for example, the donation amount). Count, Exists, and Doesn't exist don't need an attribute.

The summary 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.

Where custom field values show up

• Record detail views — the field appears on every record for its object.

• Exports — custom fields are available as columns when you export that object.

• Rules, segments, and variables — 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.

• CRM integrations — when a custom field value changes, WeGive syncs the parent record to your connected CRM (e.g., Salesforce), so the value can flow downstream where supported.

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 and exports. Choose something descriptive you won't need to rename later, since downstream rules and reports reference it.

• 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, for instance.

• 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 summary 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 type a value into a computed field on a record — change the underlying data (or the field's filters) instead.

Quick reference