Hide and show a form section

Section visibility is controlled by the section's internal name, not its display label — and ServiceNow doesn't make this obvious. When you configure a form section, ServiceNow generates an internal identifier like approval_information while showing you a friendly label like "Approval Details". Most developers grab the wrong identifier first, then waste time debugging why setSectionDisplay() appears to do nothing. The isLoading guard prevents unnecessary processing during form initialization, and managing mandatory field states alongside section visibility prevents validation errors on hidden required fields.

When to use this pattern

• Hiding approval workflows for low-priority requests to reduce form complexity
• Showing closure details only when incidents reach resolved states
• Revealing vendor information sections based on category selections in hardware requests
• Progressive disclosure in complex forms where different user types need different field groups

When NOT to use this pattern

• Don't use this for individual field visibility — use g_form.setVisible() instead for better performance
• Don't hide sections containing mandatory fields without clearing the mandatory state — form submission will fail
• Don't use this in Service Portal — sections don't exist in portal forms, use UI Policy or field visibility instead
• Don't use this when UI Policies can handle the logic — UI Policies run server-side and provide better performance for simple show/hide rules

Key behaviors and gotchas

• Section names are found in Form Design → right-click section → Properties, not from the section's display label
• Choice field values are stored as strings ('6') not integers (6) — use string comparison or == not ===
• Hidden sections still validate mandatory fields on form submission — always clear mandatory state when hiding
• The isLoading parameter prevents logic from running during form initialization, which can cause flicker
• Section visibility changes don't persist across form refreshes — complex conditional logic may need UI Policies instead
• Different form views can have different section names for the same logical grouping — test across all relevant form configurations