The Base That Outgrew Its Views
A 25,000-record Inventory table is used by warehouse staff on tablets and by a planning team on desktops. Staff complain the base 'takes forever' to load and that filters reset. Planners need to see stock levels, reorder points, and a computed 'days of supply' (stock ÷ average daily usage). The base currently has 60 views, many with heavy filters and sorts, and several formula fields that reference lookups across three linked tables. A teammate suggests adding more views so each person has their own. The tablet users mostly need to scan a barcode, confirm a quantity, and move on; the planners need analysis.
1. Why is 'add more views' the wrong instinct here, and what actually drives the slowness?
Read the worked answer
Views are saved filter/sort/field configurations over the same table; adding views does not reduce the data each client must load, and 60 views make the base harder to maintain without improving performance. Slowness on 25,000 records with heavy filters and cross-table lookups is driven by:
- Computed fields (lookups, rollups, formulas referencing them) that must resolve across linked tables for every record loaded.
- Wide views that pull many fields, including computed ones, into the client.
- Client capability: tablets loading a desktop-sized grid with many computed columns will struggle regardless of view count.
The fix is to reduce what each audience loads, not to multiply configurations.
2. How would you split the experience for tablet staff vs planners, and what would you change in the data model?
Read the worked answer
- Tablet staff: give them a minimal interface (or a narrow view) showing only barcode, quantity, and a confirm action - no computed analysis fields. This cuts payload and matches the scan-confirm task.
- Planners: a separate interface or view with stock, reorder point, and days-of-supply, loading only the fields they need.
- Data model: move 'days of supply' computation so it is not recomputed for every scan. If average daily usage is relatively stable, precompute it on a schedule (automation or synced summary) rather than as a live formula chained through lookups. Reduce lookup chains where a direct field or a periodic sync would do.
- Consolidate views: retire the 60 views down to the handful actually used, and use interfaces for role-specific layouts instead of per-person views.
3. What would you verify before concluding the base itself is the bottleneck?
Read the worked answer
- Measure, don't assume: time a load with a narrow view vs a wide view; if narrow is fast, the problem is field payload, not record count.
- Check computed-field cost: temporarily remove or freeze the heaviest lookup/rollup chains in a copy and compare load times.
- Check client/network: tablet browsers and warehouse Wi-Fi may be the real constraint; test a desktop on the same network.
- Check automation load: background automations on the table can slow writes and reads; review run volume.
- Confirm the symptom: 'filters reset' may be a per-user view behavior or a client session issue, not a performance problem at all. Verify before rebuilding.