A custom field is a field your organization adds to one type of Rhythm record. Rhythm already includes built-in fields for records such as contacts, organizations, memberships, sponsorship applications, and submission reviews. When those fields do not cover what you need to track, create a custom field for that information, such as a member's preferred conference track or an organization's industry segment.
Why Custom Fields Exist
Custom fields let you collect the details your association needs on the records you already use. You do not need to wait for Rhythm to add a built-in field. They also help when a built-in field is too limited. For example, if a built-in list does not include the choices you need, you can create a custom picklist with your exact choices and use it on your forms.
A custom field is a definition, not the value someone enters. The definition controls which record type the field belongs to, what kind of value it stores, and how forms show it. The value is saved later on each record, when someone fills in the field.
Every Field Belongs to One Record Type
When you create a custom field, you choose one record type for it. Rhythm builds the field's identifier from that record type, so that connection stays the same. If you rename the field's label later, the identifier does not change. That keeps reports, templates, and other places that use the identifier working after the rename.
- A contact field and an organization field are two separate fields. If you need "Region" on both contacts and organizations, create two custom fields, one for each record type. You maintain each field's choices separately because the fields do not share one master list.
- Values are not shared between record types. A value entered in an organization field does not appear in a contact field, and saving one field does not overwrite the other. If a contact form and an organization form both ask for "Region", they save answers to two different fields.
- A field on one record type does not show up on another. An organization custom field does not appear on that organization's memberships or registrations because those are different record types. The same rule applies across applications: an organization field you add in one Console is not visible when you view that organization from another application's record pages because the field follows the record type, not the screen. If you need the value in both places, create a field on each record type and keep the values in step yourself. Some organizations choose to do this, such as duplicating a certification status onto the contact record so they can query contact, membership, and certification data together.
- A record type's own forms may not offer the same built-in fields as another record type's forms. For example, some built-in fields available on organization forms, such as domain, are not offered on the contact forms used for signup. To capture the same kind of information there, create a custom field on the record type that the form uses.
Before you create a field, decide which record the field describes. Put "Expiration date of the organization's accreditation" on the organization. Put "Dietary requirement for this event" on the registration.
Tip
If you are not sure which record type a field belongs on, ask where people will look for it and which forms will collect it. The field must use the same record type as those forms and record pages.
This separation also matters for advanced pricing and eligibility rules at checkout. A rule checks the record type behind the transaction, so an organization-based transaction uses organization fields, not contact fields.
What Kinds of Values a Field Holds
Each custom field has a type, which controls what it stores and how people see it. Types include single-line text, multi-line text, a number, a currency amount, a date, a yes-or-no answer sometimes called a Boolean field, a picklist, a file, an image, a reference to a contact or organization, a rating, an electronic signature, and more. There are twenty-two types in all. Custom Field Types lists each one, what it stores, and when to use it.
A reference field is not limited to one feature area. Use it whenever a record needs to point to a specific contact or organization, such as linking an award application to its nominator or a committee seat to the organization it represents.
Choose the Date type for anything that is truly a date. If you create the field as plain text instead, Rhythm does not apply date formatting or date sorting, even when people enter values that look like dates.
A currency field stores a plain number. Rhythm does not convert that number between currencies, so the value should keep its defined currency symbol wherever it appears. Otherwise, the amount could be relabeled based on a visitor's location without being converted.
A File field always shows the standard upload control, even on a form where your process does not use that control to collect anything. Choose a different type if you do not want the upload button to appear. When you export a file or image field's value, such as in a query result, it appears as an internal file reference instead of a ready-to-use public web address. Retrieve the file through Rhythm rather than pasting that exported value directly into a link on an external site.
For a yes-or-no question you need to search or report on precisely, such as an opt-in to receive text messages, use a required picklist with explicit choices like "Opt-In" and "Opt-Out". That is easier to query reliably than a checkbox, which stores true, false, or blank values that are harder to search.
One type, Table/List, works differently. It stores a list of rows on the parent record, and a custom object defines each row. For example, a contact could have a table of licences, with each row storing a state, a number, and an expiry date. Custom Objects Explained: Record Types of Your Own explains custom objects.
Custom Field or Custom Object?
Use a custom field when you need one more piece of information on an existing record, such as a contact's licence number. Use a custom object when you need a new kind of record with several fields of its own, such as a licence with a state, number, and expiry date, possibly many per contact. A custom object's own fields are custom fields too. You manage them on the object's page, not in an application's setup menu. If you want several separate line items, such as more than one certification or contact number, give each one its own field, or use a custom object with one row per item. Do not format all of them into one large text field.
For a lighter need, such as flagging a subset of contacts like fellowship recipients so you can use them in eligibility or pricing criteria, a contact role can be enough. Save a custom object, or the Awards application's fuller nomination and review workflow, for cases that need more structure than a role provides.
Custom Record Actions: A Further Extensibility Option
Custom fields and custom objects cover most needs for extra data. For advanced, highly specialized requirements that do not fit a standard field or object, System & Security › Custom Record Actions lets you configure a Custom Record Action instead. Each one names the applications it applies to, and its link appears on the matching record pages in those applications. Custom Record Actions are for requirements too specialized to become standard product behavior, so start with a custom field or custom object and use this option only as a fallback for advanced, account-specific extensibility.
Picklists and Parent/Child Picklists
List fields (Picklist, Picklist (Multi-Select), Checkboxes, and Radiobuttons) give people a fixed set of choices. Each choice can show people one label while storing a shorter value in Rhythm. For example, members see "Yes, I would like to receive this newsletter" while Rhythm stores "Yes". If you later change a list field's input type, such as from Picklist (Multi-Select) to Checkboxes, or from a dropdown-style Picklist to a checklist-style field, Rhythm keeps the values already saved on records.
If you use Picklist (Multi-Select) and someone later searches for those values with a "contains text" query, avoid commas inside a choice's stored value. Contact queries have not reliably matched multi-select values that contain a comma. If you also let people type their own entry in addition to choosing from the list, test the portal's profile-editing page carefully. With that setting on, the portal has sometimes shown an extra, unusable option built by combining someone's previous choices, and selecting it fails to save. Turn the custom-values setting off, or contact Support, if you see this.
A parent/child picklist narrows one list based on the choice made in another field. You set up the child field, point it to a parent field on the same record type, and choose which child values go with each parent value. For example, a parent field Interest Area with the value "Sports" makes the child field offer only "Basketball", "Soccer", and "Baseball", while "Arts" offers a different set. The child's choices follow the selected value in the parent field, but the two fields remain separate and store their own values. To set one up, create the parent picklist and its values, create the child picklist and its values, turn on the parent/child option on the child field, then point it at the parent and choose which child values belong to each parent value.
Only a Picklist or Picklist (Multi-Select) can be the child. The parent must be a Picklist or Radiobuttons field on the same record type. Rhythm rejects a picklist that names itself as its parent, and it also rejects a parent chain that would loop back on itself. In the Console and the portal, forms narrow the child's choices when the parent changes.
A parent/child relationship only narrows the child's list of choices. It does not control whether the child field appears on the form. If you need to show or hide a field based on another answer, use a separate form-configuration setting instead of a parent/child picklist. A custom field can trigger that show/hide logic. For example, add a yes-or-no field that records whether someone is in a target group, then have the form use that field's value to decide whether to show a later field such as a chapter selection.
If the approved choices on a field that drives this kind of logic need to change later, create a new field for the driving question instead of editing the existing option values. Changing values that other fields already reference can disrupt the dependent choices, so a new field gives you a clean start while leaving the original follow-up fields intact.
How Applications Use a Field
After you define a field, every application that stores that record type can use it. A field added to contacts is available to contact forms in every Console that works with contacts.
- Forms and page layouts. A defined field is available to add to forms and page layouts for its record type. A form or layout shows the field only after you choose it in one of its field groups. If the form does not already have a field group where you need one, add one first, then edit it to select the field. For that form only, you can give the field a different label, make it required or optional, make it optional for staff in the Console, or shorten its list of choices. Removing a field from a form does not delete the field, its stored values, or anything else. The field is simply hidden there until you add it back. A calculated field can also fill in a value automatically from another field on the same form, such as deriving a region once someone chooses a country, if that mapping is defined. See Page Layouts Explained and Web Forms Explained.
- Required on one form, not everywhere. Marking a field required on a custom object does not automatically make it required everywhere the object is used. Each form or portal experience sets its own required fields, so you may still need to mark the field required on the specific form or page where it should be enforced. If a field shows the wrong required or optional behavior, check that its field group points to the intended field. A mismatched field reference can make required and optional behave unexpectedly. The built-in Email Address field in the Contact Social Lookup component cannot itself be made required. If email must be required, add a separate field, such as Secondary Email Address, to the contact form and mark that one required. Replacing the social lookup component with a plain field group is another way to require email, but it gives up the profile-photo upload that the social lookup component provides, so weigh that trade-off first.
- A form can be reused beyond the flow you built it for. If you add a field to a general-purpose form, such as the contact form used for profile updates, it appears everywhere that form is used, not only in the flow you built it for. For example, a profile-update field you add for renewal also shows up whenever a member updates their profile outside of renewal. A portal account-creation flow also uses a contact form, so you can add a consent checkbox, such as a privacy-policy acknowledgment, as a custom yes-or-no field on that form. A field collected during event registration can also be made editable from a member's own profile. Add it to the profile form or page layout the same way, then set its portal access to allow members to change it.
- Record pages. Many record pages have a Custom Fields tab. It shows each custom field that has a value, formatted for its type: dates as dates, yes-or-no answers as Yes or No, picklist answers as the choice's label, and files as a Download link. A Text (Multiple Lines) value can lose its line breaks on this tab even though the edit form preserves them, so do not expect the tab to match the form's formatting exactly. A Reference value shown here is a working link. Selecting it opens the contact or organization record it points to. Fields without a value are left out. If no custom field values are filled in, the tab reads "This record has no custom field values to display." Custom fields on a record's 360 page display in alphabetical order, and you cannot reorder or group them yourself. You can also show a field outside the Custom Fields tab. To show something like a contact's country on a profile page, add the custom field to the contact form so people can enter it, then add it as a Global Call Out in the 360 Screens configuration.
- Templates and formulas. Email templates, document merges, and formulas can refer to a custom field by its identifier. This includes custom address fields, which are available as merge fields the same way other custom fields are. The merge fields a template's merge field generator offers depend on the record or object you are merging. Different objects, such as chapters and committees, expose different fields even within the same application area, so do not expect every generator to list the same set. If a template's merge field generator does not offer the field you need, list the custom fields you expect to use in the template's own description as a reference until it does.
- Queries and reports. A query built against a custom field only returns records where that custom field has a value. It does not use a value from a similarly named standard field. Organization custom fields, such as a date field, can also be used in queries, not only on forms and page layouts. A custom field's value can also be used as a searchable field anywhere your Rhythm account lets you add custom search fields, such as an alternate name for an organization. A field's type can also affect how values behave after you change it. For example, changing an existing field from plain text to HTML can change how newly entered values are stored and displayed compared with older entries already on records.
- The API. If you work with custom fields through the API, contact field data is exposed through the shared custom field values resource rather than through a separate resource for each field.
- Quick search. Whether a custom field can be added as a field quick search reads is not something every organization can configure the same way. Some organizations have moved a custom identifier, such as an internal code, out of a custom field and into a built-in field like Organization ID specifically so members of staff could find it from quick search.
Creating a field gives you a place to store information. It does not fill itself in or trigger anything in another application. For example, a yes-or-no field named "Accepted" does not open an event registration, and a field named "Mass update" does not run a bulk change. The field stays blank on each record until someone enters a value or a form supplies a default. If you only need somewhere to store and show a value that comes from outside Rhythm, such as reference data from another system, a custom field can handle the storage and display. You still need a separate way to bring the value in because the field does not fetch it. Similarly, if a portal directory cannot show a value directly from its original source, a custom field can stand in as a workaround, as long as you keep it manually updated so the directory continues to show the right value.
What Happens Automatically
- When a record is saved, Rhythm trims extra spaces from text values, removes empty entries, and rejects any date or date-and-time value that is not recognizable as a date.
- Defaults come from the form that draws the field. A record created without a form starts with the field empty. A default only pre-fills the field. It does not stop someone from replacing it with an invalid entry later, such as a negative number where a positive quantity is expected, so treat a default as a convenience rather than validation.
- Portal access. Each field has a setting for portal members: they can change it, only see it, or never see it. A new field starts with "members can change it". Portal pages that show custom fields use this setting. The fields a particular portal page shows depend on how that page is set up.
- Deleting a field. Deleting a custom field does not erase the values already stored on records. Those values can still appear in query results after the field itself is gone. Because the underlying data remains, Support may be able to restore a deleted field, along with its history, by recreating it with the same identifier. Contact Support if you need this done.
Related Tasks
- Custom Fields: create, edit, clone, and delete custom fields.
- Custom Field Types: choose the right type.
- A Custom Field Does Not Appear Where I Expect: checks when a field is missing.