The Onboarding App That Times Out
PeopleOps at a 1,400-employee insurer built a canvas app for onboarding. Employee master data sits in a single SharePoint list with 8,200 items. The browse screen filters by Department and then by Manager; neither column is indexed, and users report waits of 30-60 seconds plus delegation warnings. A second screen shows salary bands from the same list - the maker fixed an access error by granting all 14 HR coordinators Contribute rights to the whole list. The app drives a 12-step approval using a single Power Automate flow that writes status back to the same list. Document attachments are stored as list attachments and some items now carry nine files. The maker works on this two days a month, edits the live app directly in the browser, keeps no source control, and has no test environment. Two coordinators have started keeping personal spreadsheets because the app is slow, and one has asked whether she can just be given direct list access instead.
1. Diagnose the performance problem and prescribe the data and query changes, in order of impact.
Read the worked answer
The symptoms point to design causes, not to a slow platform.
- Non-delegable, nested filters: Filter by Department and then Filter by Manager means the second operation can run only on the first page of already-retrieved records. SharePoint delegation is limited to a small set of operators and to indexed columns, with a default retrieval ceiling of 500 rows that can be raised to 2,000 in settings. With 8,200 items, most records are never queried correctly, which is both a performance and a correctness bug.
- Missing indexes: SharePoint allows a bounded number of indexed columns per list, and filters must combine indexed columns predictably. Department and Manager should be indexed, along with any Status column used by the flow.
- Attachments: nine files per item stored as list attachments inflate list payloads whenever an item is retrieved. Photos and documents belong in a document library, referenced by URL or ID.
Order of work: move attachments out of the list; add indexes; rewrite queries to use a single delegable filter with StartsWith or equality operators; add paging with an explicit sort; and replace the browse screen with a search-first pattern that requires a name or employee ID rather than loading a department.
If the list continues to grow and salary data must be protected, the durable answer is a move to Dataverse, which removes the delegation ceiling and enables column-level security. That is a licensing decision and should be raised with IT as a separate recommendation, not bundled into a bug fix.
2. Address the salary exposure. What are the options and what would you recommend?
Read the worked answer
The current control is a blanket Contribute grant to 14 people so that the app can read one column. That is a privilege escalation to solve a read problem, and it gives every coordinator edit rights to salary bands and to every other field in the list.
Options:
- Do nothing, rely on policy. Weakest option. It is unenforceable and will not survive an audit question.
- Split the list. Salary bands move to a separate list with a narrower permission set, read by the app through a connection owned by a service account, with the app displaying only the relevant band. This is achievable on SharePoint and is the realistic near-term fix. Limit: anyone with direct list access can still read it, so direct access must be group-managed and reviewed.
- Item-level permissions. Distinguishing permissions per item at 8,200 items degrades SharePoint performance and is operationally fragile. Do not use it here.
- Dataverse with column security. The correct long-term control: field-level restrictions are enforced server-side regardless of client, and audit is available. This requires premium licensing.
Recommend option 2 now, with the Contribute grant reduced to the minimum group that genuinely needs write access (likely a small PeopleOps admin group, not all 14 coordinators), and option 4 raised as the target state. Document the residual risk: a determined user with list access could still read bands, so access reviews must be scheduled quarterly, and the list should be classified as confidential with restricted sharing.
3. What must change in how this app is built and released, given the maker's two days a month and no test environment?
Read the worked answer
The delivery model, not just the app, is the risk. Editing live in the browser means every change is an unlogged production change with no rollback beyond hope, and the 12-step flow has no version discipline.
Minimum viable change set:
- Packaging: move the app, flow and any custom connectors into a solution so they can be exported, versioned and moved between environments. Store the solution in the corporate repository with a version number per release.
- Environments: a developer environment plus a production environment, even if there is no separate test environment. The maker builds and demos in dev, and only managed solution imports reach production. Connection references and environment variables should carry the differences so nothing is edited by hand after import.
- Change log and approver: a lightweight register - what changed, who approved, when deployed, how it was verified. For an app touching salary data, PeopleOps leadership should be the named approver.
- Ownership continuity: the maker's two days a month is a single point of failure. Assign a second trained maker, transfer connections to a service account or shared group rather than an individual, and document the data model and flow logic.
- Address the workaround directly: coordinators keeping personal spreadsheets is a data protection issue as well as a signal that the app is failing them. Find out which two or three screens they bypass, fix those first, and give them a defined alternative to direct list access.