62-Field Form: UI Policy, ACL, and Data Policy
The service request form has grown to 62 fields. Three UI policies hide or make mandatory about 15 fields, and two client scripts run onLoad to call GlideAjax for approver lookup. Users report the form takes 6-8 seconds to load, and some users still see the 'Budget code' field even though a UI policy is supposed to hide it. There is also a requirement that the field be non-editable for everyone except the finance role, and that imports and integrations cannot create a request without a cost center. The team wants this fixed before the next release.
1. Budget code is still visible for some users despite the UI policy. Diagnose likely causes and recommend the fix.
Read the worked answer
Diagnose before changing anything:
- Is the UI policy condition evaluated against a field that is empty at load and only populated later by the GlideAjax callback? Then the policy runs once, sees the wrong value, and never re-runs.
- Is a client script setting
g_form.setVisible('budget_code', true)after the policy runs? Client scripts and UI policies both execute, and order is not something to leave to chance. - Is the policy marked inactive or limited to a view the user is not on? Check the view and the 'inherit' setting.
Structural fix: make hiding declarative. Keep the visibility rule in a UI policy with the correct condition, remove imperative setVisible calls from client scripts, and if the condition depends on async data, have the callback trigger the policy (or call g_form.setVisible once, deliberately, from the callback).
Security caveat: if Budget code must be inaccessible, not just hidden, a UI policy is the wrong control - add a read ACL. Hidden is not the same as protected.
2. Non-editable for everyone except finance, plus a hard requirement for imports and integrations. Which mechanism for which layer?
Read the worked answer
Three separate problems, three mechanisms:
- Security (write): a write ACL on
budget_coderequiring the finance role. This is the only layer that holds against a scripted or REST update. - User experience (read-only): a UI policy that sets the field read-only unless the user has the finance role. This prevents confusion and failed saves; it is not a security control.
- Server-side enforcement for imports/integrations: a data policy (or a business rule) marking cost center mandatory on insert/update. UI policies and client scripts never execute during import or REST, so they cannot satisfy this requirement.
Judgement: do not pick one. The ACL stops the unauthorised write, the UI policy stops the frustrating form, and the data policy stops the invalid record arriving through the back door. If you only have time for one before release, ship the data policy and the ACL - they protect data; the UI policy protects feelings.
3. Cut the 6-8 second load. What do you investigate first?
Read the worked answer
Suspect the synchronous GlideAjax first. If the onLoad scripts use getXMLWait(), the browser blocks until the server answers - twice. Convert to getXMLAnswer(callback) and render the approver once it returns, with the field initially read-only or a loading indicator.
Then, in order of likely payoff:
- Consolidate the three UI policies and any scripts that touch the same fields; each one adds client-side evaluation on every change.
- Check for dot-walked fields on the form (
caller.company.name) - each can add server round-trips. - Check the number of ACLs evaluated for the table; a slow ACL condition script runs per field per record.
- Reduce the form with views or a multi-step layout; 62 fields on one section is a design problem, not just a performance one.
Measure, do not guess: use the browser network panel and the instance's client timings to confirm which call is slow before rewriting anything.