The 4-Second Grid That Only Slows Down for Managers
A case management app has a record type Case with 2.1 million rows. A read-only grid on the main dashboard queries Case and runs acceptably (about 1.2 s) for most users. A group of 40 supervisors, however, complains that the same grid takes 4+ seconds. Investigation shows supervisors are members of 6 groups, and the grid's security filters resolve to a union of 6 visibility rules; the average user is in 1 group. The grid also has a customerName column pulled via a one-to-many relationship from Customer (one Customer to many Case rows), displayed as a comma-separated list. There is no index on Case.status, which the dashboard filters on. Leadership wants the supervisor experience fixed this sprint without changing the data model.
1. Where is the performance cost most likely coming from, and what would you change first?
Read the worked answer
Two distinct costs are stacked here, and they should be separated before acting.
- Security filter fan-out. Supervisors resolve 6 visibility rules instead of 1. Appian applies row-level security as query predicates; a union of 6 rules means more predicate work and often a larger result set before paging. This is a design cost, not a database tuning cost.
- The
customerNamecolumn. A one-to-many relationship displayed as a comma-separated list forces the platform to aggregate child rows for every parent row on the page. This is frequently the dominant cost on otherwise-fine grids, and it hits supervisors harder only because they see more rows.
First change: remove the one-to-many column from the grid (or replace it with a scalar field denormalized onto Case, e.g. a primary customer name). This is reversible and requires no data model change. Second: reduce the number of visibility rules by consolidating the 6 groups into fewer, broader rules where the business meaning allows - 6 groups that all grant the same kind of access are a modeling smell. Third: the missing status index is real, but fixing it helps everyone equally and does not explain the supervisor-specific gap, so it is lower priority for this symptom.
The reasoning to carry forward: when one user cohort is slower on the same query, look for what differs about their row visibility or their column-level aggregation, not at global indexes.
2. A developer proposes caching the grid's data in a process variable refreshed hourly. Evaluate this against the alternatives.
Read the worked answer
This is a tempting but usually wrong fix, and the exam wants you to say why.
Problems with hourly caching:
- Case data is the kind of data users act on. A supervisor seeing a case that was reassigned 50 minutes ago will make a wrong decision; staleness in an operational queue is a correctness bug, not a performance tradeoff.
- A process-variable cache is not shared across users - each session holds its own copy, so 40 supervisors means 40 refreshes, not one. The cost moves rather than disappears.
- Security: a cached result set must still be filtered per viewer. If you cache post-filter data you risk leaking rows; if you cache pre-filter data you have not saved the expensive part.
Better alternatives, in order:
- Fix the query shape (drop the one-to-many column, trim columns to what the grid shows).
- Reduce rows returned with a default filter (e.g. open cases only) and let users widen it deliberately.
- If a genuinely expensive aggregate is needed, compute it in a scheduled process into a dedicated summary record type that is cheap to query, and accept documented staleness there - for a count or a dashboard tile, not for the working queue.
The judgment: caching is appropriate for derived, tolerant-of-staleness data. It is not appropriate as a bandage over a query that is simply shaped badly.