6.1 Record List Configuration, Headers & Views
Key Takeaways
User filters can be changed or cleared; a default user-filter selection is not authorization.
Record-level security and sync filters serve different purposes from interactive list filters.
Summary is the first record view; additional views organize details and can use record-view security rules or expressions.
Pass record context into typed interface inputs and query additional related data only when needed.
Record Lists, Headers, and Views
A record list helps users find an entity. A record view helps them understand one selected entity. The record header maintains context as they navigate among views. Keeping those responsibilities separate makes a case-management application easier to build and easier to reason about on the Associate Developer exam.
For example, a Support Case list may show case number, title, priority, and owner. Selecting a case opens its Summary view; additional views might show documents and work orders. A related action can update the selected case. The list, view, and action can all use the same underlying record type without becoming the same design object.
Build a Useful List
Configure columns around the user's decisions. Include a recognizable identifier, the main descriptive field, and enough status information to choose the correct row. Select appropriate sorting, paging, search, and user filters. A fifty-column table copied from the source database is rarely a useful work queue.
| List feature | Purpose | Check before release |
|---|---|---|
| Column | Communicates one aspect of each entity | Label, value, formatting, and sort field agree |
| Search | Finds records using supported searchable fields | Search a known identifier and a meaningful phrase |
| User filter | Lets the reader narrow the result set | Choices, default selection, clearing, and combinations work |
| Record link | Opens one selected entity | The identifier belongs to that row |
| List action | Starts an operation such as creating a case | Process security and start form are configured |
Grid presentation suits comparison across structured fields. Feed-style presentation, available in applicable record configurations, emphasizes descriptive items. Choose the presentation supported by the record type and appropriate to the task. Do not treat record lists as a generic social feed or assume every style supports the same features.
Filtering and Authorization
A user filter is an interactive control such as a status or date-range selector. Users can change or clear it. Its configured default selection is a convenience. Clearing Open to see Closed cases should not grant access to confidential cases.
Sync filters control the data included in the synchronized dataset. Record-level security, including supported security expressions, controls access to rows. Older documentation may call some configurations default filters; current synced-record terminology distinguishes security expressions from ordinary user-filter defaults. Identify the actual configuration rather than relying on the word default.
User filters are not merely client-side filters over the currently visible page. Record-backed components can apply the selected conditions when retrieving the complete matching result set. Otherwise a user filtering a hundred-page list would incorrectly search only the first page. Test combined filters and reset paging when appropriate in custom query-driven interfaces.
For an operational list that initially shows active cases but permits historical browsing, use a user filter defaulting to Active. For a rule that certain users may never retrieve restricted cases, configure record-level security. If archived cases must not enter this record type at all, consider a sync filter and its effect on every consuming screen.
Configure the Header
The header should identify the selected entity clearly. A case number plus a short title is more useful than a generic label such as Case Details. Use the record designer's title configuration or an expression supported in that context. A related customer name can be included when the required relationship data is available.
Review background, header positioning, and views in the context of the site's branding. Avoid relying only on a color to communicate status. A red indicator should include readable status text. Keep detailed commentary in the appropriate interface instead of making the header a second full dashboard.
Configure Views
Appian provides a Summary view, and applicable default views include News and Related Actions. Summary is the first view and remains visible to users who can see the record. Additional views organize distinct information such as financial history, documents, or fulfillment details. Default News and Related Actions views can be hidden when unnecessary.
For each custom view, create or select an interface, configure its rule inputs, and give the view a meaningful name. In Views and Actions Security, configure supported security rules or a security expression to determine who can see the view and when. Current documentation calls older visibility expressions security expressions. View access does not independently secure every underlying interface, query, or process; configure their relevant permissions as well.
A selected view evaluates its interface. Avoid loading large datasets for every possible view inside the Summary interface. Query only what that view needs and give related collections bounded selections or their own record-backed grids. This helps the detail experience remain responsive as the entity accumulates history.
Pass the Record Context
rv!identifier supplies the current record's identifier. rv!record supplies record data in supported record configuration contexts. A typed record input is useful for generated views and reusable interfaces. The view configuration passes those context values into ri! inputs; the reusable interface does not acquire arbitrary record variables automatically.
/* In a record-view interface configuration; replace objects using typeahead. */
rule!CASE_caseSummary(
case: rv!record
)
The called interface defines ri!case with the Case record type and uses field references to display its values. Alternatively, it can accept an identifier and perform a deliberate bounded query. Choose based on the data contract and the fields the screen needs.
Do not assume rv!record contains every row from every relationship. Check the data supplied to the view and retrieve additional related data explicitly when needed. Conversely, do not repeat a query solely to rediscover data already passed into the interface. Inspect the actual input and returned shape before optimizing.
Worked Case Review
A service desk needs agents to find active cases and managers to review costs. Build a record list containing case number, subject, priority, and assigned agent. Give its Status user filter a default of Open while allowing users to clear it. Configure Summary to display the case's principal fields and a bounded task list. Add a Costs view visible to the finance group.
Test as an ordinary agent and a finance manager. Confirm both the visible tabs and the rows they can retrieve. Test a deep link to a record the agent cannot access, a record with no tasks, and a search that returns no cases. The empty result should be understandable without confusing it with a query or authorization failure.
Takeaway: Build discovery in the list, context in the header, detail in views, and authorization in the relevant security configuration.
Sources checked 2026-10-18: record views, record-view security, record-level security, and read-only grids.
A Case list should initially show Open cases, but users must be able to clear that selection and browse other authorized statuses. What should the developer configure?
A Status user filter with an Open default selection
A security expression that permanently hides every non-Open case
A sync filter that excludes all historical data
A hidden required field on the Summary view
A record view calls an interface with rv!record mapped to a typed rule input. What should the interface developer assume?
Every related record is automatically present without limits
The input supplies record context; inspect available fields and query additional related data when needed
The interface can directly modify process properties
The input bypasses record-level security
An application architect wants to restrict an "Audit & Compliance History" view on a Case record so that it only renders for members of the "Compliance Officers" user group. Where and how should this restriction be configured?
Delete the view from the Record Type and rebuild it as a standalone Process Model
Set a Default Filter on the Record Type that filters out audit rows for non-compliance users
Configure a security rule or security expression for that custom view, checking membership in the Compliance Officers group
Change the record list presentation style from Grid style to Feed style
Sections you finish are checked off in the contents.