Custom Field Types Reference

DonorPoint supports 14 types of custom fields. All types share a set of common properties, and each type has additional type-specific settings.

Common Properties (All Types)

Rendered Rule

The Rendered Rule is an EL expression that evaluates to "true" or "false". When it evaluates to "false", the field is hidden from the form. This enables conditional forms — showing or hiding fields based on other field values:

#{contact.get('EmploymentStatus') != null and contact.get('EmploymentStatus').value eq 'RETIRED'}

When ReRender Panel is checked, any change to this field causes the form to re-evaluate all Rendered Rules, updating the visibility of all fields simultaneously.

Accessing Custom Field Values in Scripts

Custom field values are accessed via the get() function:

// Get the value of a custom field named 'DepartmentCode' on a contact:
var dept = contact.get('DepartmentCode');
if (dept != null && dept.value != '') {
    // use dept.value
}

Note: get() returns a custom property value object, not the value directly. Always check for null before accessing .value. For text areas (CLOB type), use .text instead of .value.

Field Types

Text Field (String)

A single-line text input.

• Length — maximum character count (default 80, maximum 255)

Text Area (CLOB)

A multi-line text input (comment box).

• Length — determines the number of rows displayed (rows = length ÷ 80)
• Value is accessed via .text (not .value) in scripts

Number (Integer)

An integer number input with validation.

• Use for counts, years, ID numbers, etc.

Number (Decimal)

A decimal number input.

• Decimal Places — number of decimal digits to accept

Checkbox (Boolean)

A single checkbox for yes/no values.

• Value is accessed via .checked in scripts

Dropdown (Enum)

A drop-down selection from a defined list of values.

• Values — the list of options; manage on the Values tab
• Radio — when checked, renders as radio buttons instead of a drop-down
• No Selection Label — placeholder text for the “please select” option

Multi-Select List (Listbox)

A list box or checkbox set for selecting multiple values.

• Values — the list of options
• Checkbox — when checked, renders as a checkbox group instead of a list box

Date

A date picker.

• Value is a date object; format for display using EL date formatting functions

Color

A color picker returning a hex color value.

URL

A text input that validates as a URL and renders as a clickable link.

Image Upload

An image upload field.

• The uploaded image is stored server-side
• .value returns a URL to access the image
• .fileName, .size, .contentType provide file metadata

File Upload

A file upload field for any document type.

• Accepted Types — MIME type restriction (e.g., pdf|docx|xlsx)
• Maximum size: 16MB
• .value returns a URL to download the file
• .fileName, .size, .contentType, .data provide file metadata

Lookup Table

A shared reference list with autocomplete search.

• The lookup table maintains a list of entries that can be shared across multiple custom fields
• Suggestion Box — when checked, renders as an autocomplete input instead of a list

Lookup Entry

A reference to a specific entry within a Lookup Table.

Where Custom Fields Are Used

Custom fields can be added to the following entities:

Custom fields added to pages and items appear on forms when rendered. Custom field data appears automatically in reports. Custom fields can be included in imports.

Integration Codes

In addition to user-facing custom fields, Integration Codes are custom fields configured with the Hidden property set. They are invisible to donors but accessible in scripts and reports:

// Access an integration code on a campaign (form):
campaign.get('GL_CODE').value

// Access an integration code on a payment method:
purchaseOrder.payment.paymentMethod.get('PaymentType').value

// Access an integration code on a fund:
orderItem.fund.get('AgencyCode').value

Integration codes appear automatically in detailed reports alongside standard fields, making them ideal for GL account codes, external system IDs, and other back-office identifiers.

Important Notes

Reuse with care: Once a custom field has been created, it can be reused across multiple pages, items, or entities. If a field is in use in more than one place, a warning appears at the top of the field’s edit page. Changes to the field definition (name, prompt text, rendered rule, etc.) affect every location where it is used.

Naming: Name your custom fields clearly so you can identify and reuse them in the future. A field named “Department” is much easier to find and use correctly than one named “Field 1”.