A calculated field fills in a field by following a rule you define. You write an expression, such as “first name followed by last name” or “Yes when the member’s chapter is in the western region.” Each time that type of record is saved, Rhythm evaluates the expression and writes the result into the field. Because staff do not type the value manually, it stays current instead of becoming outdated.
Why Calculated Fields Exist
Some values naturally come from other values, such as a full name from its parts, a region from a chapter, or a flag from a date. When staff enter those values by hand, they can forget them, mistype them, or leave them unchanged after the source value changes. A rule written once refreshes the value every time the record is saved, so the same value appears on screens, in queries, and in exports.
Where They Apply
Calculated-field rules can fill in:
- Fields of Rhythm's own record types, such as contacts or memberships. You manage the rules for each record type in System & Security › Calculated Fields, where you can also turn calculations on or off for that entire record type.
- Columns of a custom object's rows. You manage a custom object's rules on the object itself, on its Calculated Fields tab. Custom-object rows belong to the records that hold them, so Rhythm calculates those columns when the parent record is saved. See Custom Objects Explained: Record Types of Your Own.
A rule can write to a standard field or to one of your custom fields. For an overview of custom fields, see Custom Fields Explained.
How a Rule Works
Each rule has four parts:
- A target field is the field the rule writes to.
- A description explains why the rule exists in one sentence.
- A calculation expression produces the value.
- A condition is optional. It is a second expression that decides, record by record, whether the rule runs. For example, an early-bird flag might apply only to registrations made before a date.
flowchart LR
A[A record is saved] --> B[Rules for that record type run in order]
B --> C{Does the rule have a condition?}
C -->|No| E[Rhythm works out the value]
C -->|Yes, and true| E
C -->|Yes, and false| F[Rhythm skips this rule]
E --> G{Did the expression work?}
G -->|Yes| H[Rhythm writes the value into the field]
G -->|No| I[Rhythm notes the error on the record]
H --> J[The record is saved]
I --> J
F --> J
The Rules and Limits
Calculated fields are an advanced configuration, so use them only when you are comfortable writing expressions. If you are not, contact Rhythm Support for help. Rhythm runs a calculation before the record is saved, so a formula that creates an invalid record can make record creation or updates fail across your account, not just on the record you tested.
- Rules run on every save of the record type, no matter which application saves the record. If the record is not saved, the value stays as it is. If the calculation depends on a related or linked value, such as an address kept on a separate record, Rhythm does not rerun it when only that related value changes. The rule runs again only when the record that holds the calculated field is saved.
- A calculated field looks at the values available on the record and form being saved. If the calculation reads a field, such as Mailing Address, and that field is not on the form used to edit and save the record, the calculation has nothing to use and leaves the target field blank. This also applies to records created or imported without that field on their form.
- List and multi-select fields are treated as string arrays in expressions. Because of that, a function such as
length()on the normal field accessor does not reliably count how many values are selected. When you need to count or otherwise work with a multi-select field's raw values, use the matching field name with an__arraysuffix instead. - Calculated fields run only when the record is saved, not when someone opens or loads a form. To clear or set a value automatically as a form loads, use a form hook instead of a calculated field.
- The result replaces the field's value, including a value someone typed there.
- Rules run in their listed order. A later rule can use a value an earlier rule just wrote, so place a total after the subtotal it uses.
- A change to the rules reaches saves within about ten seconds.
- Existing records are not recalculated when you change a rule. Each record gets the new value the next time it is saved, including when you first add a rule. To make existing records pick up a new or changed rule right away, mass update them with a value that does not otherwise matter, such as toggling a temporary Yes/No custom field. A mass update resaves each record and triggers the rule; remove the temporary field afterward.
- Removing a rule stops it running, but records keep the last value it wrote.
- Switching calculations off for a record type keeps its rules but stops all of them from running.
- Expressions are not checked when you save a rule. In the rule dialog, This expression is valid. appears for any text you type, so you see mistakes only when records are saved.
What Happens When a Rule Fails
A rule can work for most records and fail on others, such as when a date it uses is empty or a field has text where the expression expects a number. When that happens, Rhythm still saves the record, notes the failure on the record, and writes nothing for the failed rule.
If a calculation that used to work stops filling in some records after you change its formula, check how the formula’s fields work together. For example, address-related criteria such as preferred address versus mailing address, or a newly added state condition, can leave some records unmatched. Also check the formula’s structure. An expression such as a jsonLookup mapping must format source values and results correctly, because a malformed expression can fail with no obvious sign beyond the field staying blank.
To check failures on a record, open the record's options menu. If the record has failures, the menu shows View Calculated Field Errors with a red badge that counts them. That option opens Field Calculation Errors, which says The following calculated fields experienced an error the last time they were saved:. The window has a Field column for the field’s stored name, not its label, and an Error column. It shows up to eight rows; if there are more, sort by a column to bring other rows into view. You see this option on record pages that offer it, such as custom-object pages. There is no list of failures across all records.
A different kind of mistake can stop records from saving. The calculated fields screen warns: Field calculations are applied before a record is saved, and if your calculation formula causes an invalid record to be created, record creation/modification will begin to fail in your instance. If a rule writes a value the record cannot accept, saving that kind of record can fail everywhere. Test every new rule on one record before you rely on it.
An Example
An association keeps a custom field, Region, on its contacts and uses a calculated field to fill it from the contact's chapter. Chapters A, B, and C return West, and the rest return East. Staff never type the region, and Rhythm sets it correctly on every save.
Later, the association adds chapter D in the west. New contacts in chapter D get East because the expression still lists only A, B, and C. To fix it, add chapter D to the expression. Contacts already in chapter D pick up West the next time each one is saved.
The lesson is straightforward: when an expression names specific values, such as chapters, types, or statuses, update it whenever those values change.
For address-based categorization, such as assigning a region from a contact's preferred address, a large explicit list of postal codes becomes hard to maintain once you also need to combine it with state or region criteria. Minimum and maximum postal code ranges, with a region set for each range, are usually easier to maintain than an explicit list. You can then fall back to the normal anniversary-style logic for any value outside your ranges.
Another reusable pattern is a lookup function that maps source values to output values: jsonLookup(sourceField, { "Output A": ["Input 1", "Input 2"], "Output B": ["Input 3"] }). This is useful when an organization custom field should take its value from another custom field on the same organization. It returns "Output A" when the source field holds "Input 1" or "Input 2", and "Output B" when it holds "Input 3".
A Yes/No checkbox that should check itself when an organization's country is on a list you choose follows the same shape, but its input comes from the address instead of a plain custom field. Because the address lives on a related part of the record rather than as a field of its own, getting the exact reference right can take some trial and error; copy the country field's reference from the merge-field or rule-condition picker instead of typing it from memory, and confirm the checkbox sets correctly on one test record before you rely on the rule.
Before you change an existing rule's expression, copy it into a separate text document. Make your edits on the copy, then paste the finished expression back into the calculated field. This keeps the original available if you need to roll back.
Calculated Fields and Other Expressions
Rhythm uses expressions in many places, so they are easy to mix up. Most expressions answer a yes-or-no question, such as whether a form question is shown, whether a rule applies, or whether something is allowed. Those expressions do not store anything. A calculated field is different because it writes a value into a field. If you want to store a value on the record, such as Yes or No in a custom field, create a calculated field for that field under System & Security › Calculated Fields or on the custom object, not an expression somewhere else. See Rules and Expressions Explained.