5.2 Record Relationships & Custom Record Fields

Record Relationships and Calculated Fields

Record relationships describe how business entities connect. A Request belongs to one Requester; a Requester may have many Requests. Defining that connection once lets interfaces and queries reference related data consistently. The exam tests the ability to configure the relationship, recognize its direction, and choose the right field reference rather than querying one related row inside every grid cell.

Begin with a data model. Write down the identifier on each entity and the matching field on the other side. Suppose Customer has unique id values and Order has customerId. Matching Customer.id to Order.customerId yields one-to-many from Customer to Order and many-to-one in reverse. A field containing a customer's display name is a fragile substitute because names can repeat or change.

Configure and Test the Relationship

Open the base record type's data model, add a relationship, choose the related record type, and specify the matching fields and cardinality. Select a descriptive relationship name such as customer or orders. Review the reverse relationship if the design experience offers it. Both directions must reflect the actual data.

Use test data with more than one child per parent and at least one parent with no children. A model tested only with one order per customer may hide an incorrect one-to-one assumption. Also test a missing or invalid foreign key. A relationship definition does not independently clean source data or create a database foreign-key constraint.

Relationships can connect supported record types across sources. Feature availability depends on the source and access method; current Direct Data Access with features enabled supports capabilities that legacy unsynced record types lack. Do not infer support solely from the word unsynced. Verify the actual record type configuration.

Understand Field References

The following shortened references illustrate the expression editor's display notation. Insert real object references using typeahead in your environment; names in a study example are not pre-existing objects.

recordType!Order.fields.orderTotal
recordType!Order.relationships.customer.fields.customerName
recordType!Customer.relationships.orders.fields.orderTotal

A reference identifies a field; it is not the field's value for every record. In a record-backed read-only grid, the row supplies the value:

a!gridColumn(
  label: "Customer",
  sortField: recordType!Order.relationships.customer.fields.customerName,
  value: fv!row[recordType!Order.relationships.customer.fields.customerName]
)

The Customer path returns a scalar value for each Order when the relationship is many-to-one. A one-to-many path can return a collection. Decide whether the screen needs the newest child, a child list, or a summary. Returning a related list does not mean every child is returned without limits; configure related-record selection and paging deliberately.

Custom Record Fields

A custom record field derives information from record data without adding that same field to the source table. Examples include a formatted name, a category, elapsed days, or an aggregate of related rows. Choose the field's evaluation time deliberately.

• Sync-time evaluation computes a value when data syncs. It suits calculations based on relatively stable source fields, such as combining first and last names.
• Real-time evaluation computes a value when it is referenced. It suits relative dates and supported calculations over related data.

A sync-time calculation involving today's date does not advance merely because midnight passes. For a live age or overdue-days calculation, use the supported real-time field builder and functions, or calculate the display separately if query sorting is unnecessary. Real-time custom fields use Appian's supported custom-field functions; an arbitrary SAIL expression cannot be pasted into every field type.

Templates are configuration aids, not a universal bracket-token language. Use the field designer to select fields, operators, and supported expressions. Preview the generated configuration and expected results. Field references in these contexts come from the designer; invented variables such as fv!dueDate are not automatically supplied for any field name.

Choose a Computation Location

Consider a Customer grid that needs to sort customers by open-case count. Calculating a count only in each displayed cell does not provide a queryable sort field for all customers. A supported aggregate custom field can expose the calculation as part of the record model. Alternatively, an aggregation query may be appropriate for a report. The choice depends on whether the application needs entity rows with a reusable derived field or grouped report results.

Do not query all cases separately for every visible customer. Use configured relationships, supported aggregates, or a batched query. Validate the count with a small known dataset: a customer with zero cases, one open case, and several closed cases reveals whether the aggregate filter matches the intended meaning.

Record-Level Security

Object permissions and record-level security answer different questions. Object security governs access to the record type; record-level rules govern which entity instances the execution user can retrieve. Test both. A working administrator account is insufficient evidence that a support agent sees the correct rows.

Appian applies record-level security in record queries and related-data use, subject to documented context rules. In particular, a rule that finds users in related fields does not automatically inherit the related record's own authorization during that rule's evaluation. Use the supported option for users who can view related records when that inheritance is required.

A Web API uses its authenticated execution context. It does not inherit the identity of an anonymous visitor just because the visitor initiated a request. A service account entitled to broad data must expose only the intended response. Likewise, a direct data-store query does not gain record-level restrictions merely because a corresponding record type exists.

Worked Design Review

A service team creates Customer and Support Case records. The relationship matches Customer.id to SupportCase.customerId. The Customer list shows the customer's name and a reusable open-case count. A customer detail view includes a separately configured list of cases. Support technicians can retrieve only their permitted cases; account managers receive the customer access required by the business policy.

Test a customer with no cases, two open cases, and one closed case. The count should be two. Test as a technician who can see only one case, and verify whether the chosen aggregate's documented security behavior meets the policy before publishing the report. This prevents a seemingly harmless count from disclosing unintended information.

Takeaway: Cardinality, query shape, calculation timing, and authorization all affect what a relationship-based screen means.

Sources checked 2026-10-18: custom record fields, record-level security, and record query configuration.