Custom Workspace UI Action – Export Only Visible Form Fields to Excel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi Team,
I have a requirement in a Custom Workspace where I created a UI Action button (Export to Excel) on a form.
Requirement:
When the user clicks the Export Excel UI Action from Workspace:
The Excel file should contain only the fields that are currently displayed on the Workspace form
Only the visible form fields
The exported Excel should include the field labels and their corresponding record data
Fields that are hidden / not present on the form should NOT be exported
Context:
Workspace: Custom Workspace
UI Action: Workspace-compatibleForm is built using UI Builder components
Export should be dynamic
Questions:
Is there any OOTB way to get the list of visible form fields in Workspace during a UI Action execution?
If not supported OOTB, what is the recommended best-practice approach to achieve this?
Any suggestions, examples, or documentation references would be very helpful.
Thanks in advance!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
I doubt you get list of visible form fields in workspace
So this requirement is not achievable based on my experience
💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏
Ankur
✨ Certified Technical Architect || ✨ 9x ServiceNow MVP || ✨ ServiceNow Community Leader
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
REFINED REQUIREMENT: Custom Workspace UI Action – Export Only Visible Form Fields to Excel
STORY TITLE
As a Workspace User, I want to export only the visible form fields to Excel so that I can share relevant record data without including hidden or unnecessary information.
SHORT DESCRIPTION
Create a UI Action button in Custom Workspace that exports the currently displayed form fields and their values to an Excel file, excluding any hidden or non-rendered fields.
DETAILED DESCRIPTION
Business Context and Value
Workspace users need to export record data for reporting, sharing with stakeholders, or offline analysis. Currently, standard export options either export all fields or require manual configuration. This creates inefficiency when users only need the specific fields visible on their current form view.
Current State
Users must either export all record fields (including irrelevant data) or manually copy field values from the form. There is no dynamic export option that respects the current form layout in Workspace.
Desired State
A single-click "Export to Excel" button that intelligently captures only the fields rendered on the current Workspace form and exports them with proper labels and values.
User Journey
User opens a record in Custom Workspace
User reviews the form (which may have conditional field visibility)
User clicks "Export to Excel" UI Action
System identifies all currently visible form fields
System generates Excel file with field labels and corresponding values
User downloads the Excel file
Success Metrics
• Reduction in time spent manually extracting form data by 80%• User adoption rate of 70% within first quarter• Zero incidents of sensitive hidden field data being inadvertently exported
ACCEPTANCE CRITERIA
Scenario 1: Basic Export Functionality
Given: A user has a record open in Custom Workspace with 10 visible form fieldsWhen: The user clicks the "Export to Excel" UI Action buttonThen: An Excel file downloads containing exactly those 10 fields with labels in Column A and values in Column B
Scenario 2: Conditional Field Visibility Respected
Given: A form has Field X configured to show only when Field Y equals "Active"And: Field Y currently equals "Inactive" (so Field X is hidden)When: The user clicks "Export to Excel"Then: Field X is NOT included in the exported Excel file
Scenario 3: Reference Field Handling
Given: A form contains a reference field (for example, Assigned To)When: The user clicks "Export to Excel"Then: The Excel displays the display value (for example, "John Smith") not the sys_id
Scenario 4: Field Label Accuracy
Given: A form field has a custom label configured in the form layoutWhen: The user clicks "Export to Excel"Then: The Excel uses the custom label, not the dictionary field label
Scenario 5: Empty Field Handling
Given: A visible form field has no value (empty or null)When: The user clicks "Export to Excel"Then: The field appears in Excel with an empty value cell (field is not omitted)
Scenario 6: Date and Time Field Formatting
Given: A form contains date/time fieldsWhen: The user clicks "Export to Excel"Then: Dates export in user's preferred format as configured in their profile
Scenario 7: Error Handling - No Visible Fields
Given: An edge case where no form fields are visibleWhen: The user clicks "Export to Excel"Then: A user-friendly message displays: "No fields available to export"
Scenario 8: Large Form Performance
Given: A form with 50 or more visible fieldsWhen: The user clicks "Export to Excel"Then: The export completes within 5 seconds
Scenario 9: UI Action Visibility
Given: A user without export permissions (if ACL restricted)When: The user views the formThen: The "Export to Excel" button is not visible
TECHNICAL REQUIREMENTS
Platform Requirements
• ServiceNow Platform Version: Tokyo or higher (Workspace UI Actions supported)• Browser Compatibility: Chrome (latest), Edge (latest), Firefox (latest)• Custom Workspace must be built using UI Builder
Architecture Approach
Since there is no OOTB method to retrieve visible form fields from a Workspace form during UI Action execution, the recommended approach involves:
Option A: Client-Side Field Detection (Recommended)
1. UI Action triggers client-side script in Workspace
2. Client script queries the DOM or uses Workspace APIs to identify rendered field elements
3. Field names are collected and passed to a Script Include via GlideAjax
4. Server-side script retrieves field values and generates Excel
5. Excel file is returned to client for download
Option B: Form Configuration Metadata Approach
Store form field configuration in a custom table or system property
UI Action reads the configuration to determine expected visible fields
Server-side generates Excel based on configuration
Limitation: Does not account for runtime conditional visibility
Option C: Hybrid Approach (Best Practice)
Use Workspace declarative actions to capture form context
Leverage Now Experience UI Framework APIs (if available) to get rendered components
Pass field list to server for processing
Generate Excel using ExcelJS or similar library
Integration Points
• UI Builder Form Component APIs
• GlideRecord for data retrieval
• GlideAjax for client-server communication
• Attachment API or direct download mechanism for file delivery
Performance Requirements
• Field detection must complete within 2 seconds• Excel generation must complete within 3 seconds• Total export time must not exceed 5 seconds for forms with up to 100 fields
Security Considerations
• Respect existing field-level ACLs (user should not export fields they cannot read)• Validate field list server-side to prevent injection attacks• Audit log each export action with user, record, timestamp, and field count• Ensure exported file does not contain sys_ids for sensitive reference fields unless required
DEPENDENCIES
Upstream Dependencies (What This Needs)
• Custom Workspace must be deployed and functional• Form layouts must be configured in UI Builder• User must have read access to the target table• Excel generation library or method must be available (for example, ExcelJS, GlideSysAttachment)
Downstream Dependencies (What Needs This)
• None identified; this is a self-contained feature
External System Dependencies
• None; Excel generation is handled within ServiceNow
Data Dependencies
• Real-time access to the record being viewed• Access to form field metadata (labels, types)
ASSUMPTIONS
Business Assumptions
• Users have legitimate business need to export visible form data• Export frequency will be moderate (not bulk/mass exports)• Single record export is sufficient (multi-record export not required)
Technical Assumptions
• UI Builder Workspace provides some mechanism to access rendered form components (via DOM, API, or event)• The Now Experience framework allows client scripts to execute from UI Actions• Excel file generation can be performed server-side without third-party integrations
Resource Assumptions
• Development team has experience with UI Builder and Workspace customization• Testing environment mirrors production Workspace configuration
RISKS
Risk 1: No Native API for Visible Field Detection
Likelihood: HighImpact: HighDescription: ServiceNow may not provide an API to programmatically retrieve currently rendered form fields in WorkspaceMitigation: Implement DOM inspection as fallback; engage ServiceNow support for guidance; consider form configuration metadata approach
Risk 2: Performance Degradation with Large Forms
Likelihood: MediumImpact: MediumDescription: Forms with many fields or complex conditional logic may slow exportMitigation: Implement field count limits; add loading indicator; optimize queries
Risk 3: Workspace Version Compatibility
Likelihood: MediumImpact: HighDescription: Future Workspace updates may change how forms are rendered, breaking field detectionMitigation: Abstract field detection logic into maintainable component; document dependencies; include in regression testing
Risk 4: Security Exposure
Likelihood: LowImpact: HighDescription: Export mechanism could potentially expose fields user shouldn't seeMitigation: Server-side ACL validation for every field before including in export
Risk 5: Browser Compatibility Issues
Likelihood: LowImpact: MediumDescription: Excel download mechanism may behave differently across browsersMitigation: Test across all supported browsers; use standard download approaches
OUT OF SCOPE
• Exporting multiple records at once (bulk export)• Exporting to formats other than Excel (for example, PDF, CSV)• Customizing Excel formatting (colors, fonts, column widths)• Exporting related list data• Exporting form attachments• Scheduling automated exports• Exporting from Classic UI or Service Portal (Workspace only)• Creating email functionality with export attached
DEFINITION OF DONE
Development Complete
• UI Action created and configured for Custom Workspace• Client-side script implemented for visible field detection• Server-side Script Include created for Excel generation• Download mechanism implemented and functional
Testing Complete
• Unit tests cover all acceptance criteria scenarios• Integration testing completed in DEV environment• User Acceptance Testing (UAT) passed with sign-off• Performance testing validates 5-second requirement• Security review completed (ACL validation confirmed)• Cross-browser testing completed
Documentation Complete
• Technical documentation for maintenance team• User guide or knowledge article for end users• Release notes prepared
Deployment Ready
• Code reviewed and approved by peer• Update set or application scope ready for promotion• Rollback plan documented
QUESTIONS REQUIRING CLARIFICATION
Before development begins, please confirm the following:
Target Table(s): Which specific table(s) in Custom Workspace require this export functionality? Or should this work across all Workspace forms?
User Permissions: Should export capability be restricted to specific roles? If yes, which roles?
Audit Requirements: Is there a requirement to log/audit each export action for compliance?
Excel File Naming Convention: What should the exported file be named? (for example, TableName_RecordNumber_Timestamp.xlsx)
Reference Field Depth: For reference fields, should we export just the display value, or include additional details (for example, email for user references)?
Journal/History Fields: Should journal fields (for example, work notes, comments) be included if visible? If yes, how should multiple entries be formatted?
Attachment Handling: If an attachment field is visible, should the Excel include the attachment name, or is this out of scope?
Localization: Should field labels be exported in the user's language preference?
TECHNICAL INVESTIGATION NOTES
Regarding OOTB Capability:
Based on current ServiceNow documentation, there is NO out-of-the-box method to programmatically retrieve the list of visible form fields during UI Action execution in Workspace. The recommended approaches are:
Approach 1: DOM Inspection (Most Dynamic)
Use client-side JavaScript to inspect the rendered form and extract field names from data attributes on form elements.
Pros: Accurately reflects runtime visibilityCons: Fragile if DOM structure changes; requires careful selector management
Approach 2: Workspace Declarative Actions with Payload
Configure the declarative action to pass form context. Limited by what Workspace exposes in the action payload.
Pros: Supported approach using framework capabilitiesCons: May not include all needed field metadata
Approach 3: Form Section/View Configuration Query
Query sys_ui_section and sys_ui_element for the form view being used.
Pros: Server-side approach; stableCons: Does not account for UI Policy or Client Script conditional visibility
Recommended Best Practice:
Implement a hybrid solution combining DOM inspection for accuracy with server-side validation for security. Encapsulate the logic in reusable components that can be updated if ServiceNow provides better APIs in future releases.
RELATED DOCUMENTATION REFERENCES
• ServiceNow Docs: UI Actions for Workspace
• ServiceNow Docs: Now Experience UI Framework
• ServiceNow Docs: GlideAjax
• ServiceNow Community: Workspace Customization Best Practices
• ServiceNow Developer Blog: Working with UI Builder Forms
Did I captured your requirements correctly?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Regarding OOTB Capability:
Based on current ServiceNow documentation, there is NO out-of-the-box method to programmatically retrieve the list of visible form fields during UI Action execution in Workspace. The recommended approaches are:
Approach 1: DOM Inspection (Most Dynamic)
Use client-side JavaScript to inspect the rendered form and extract field names from data attributes on form elements.
Pros: Accurately reflects runtime visibilityCons: Fragile if DOM structure changes; requires careful selector management
Approach 2: Workspace Declarative Actions with Payload
Configure the declarative action to pass form context. Limited by what Workspace exposes in the action payload.
Pros: Supported approach using framework capabilitiesCons: May not include all needed field metadata
Approach 3: Form Section/View Configuration Query
Query sys_ui_section and sys_ui_element for the form view being used.
Pros: Server-side approach; stableCons: Does not account for UI Policy or Client Script conditional visibility
Recommended Best Practice:
Implement a hybrid solution combining DOM inspection for accuracy with server-side validation for security. Encapsulate the logic in reusable components that can be updated if ServiceNow provides better APIs in future releases.
RELATED DOCUMENTATION REFERENCES
• ServiceNow Docs: UI Actions for Workspace
• ServiceNow Docs: Now Experience UI Framework
• ServiceNow Docs: GlideAjax
• ServiceNow Community: Workspace Customization Best Practices
• ServiceNow Developer Blog: Working with UI Builder Forms
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Glideform has at least these two methods in workspaces to check if a field is visible: isVisible and isFieldVisible. I recall isVisible gives false negatives (at least on classic ui) if the visibility is toggled by setting a non-visible empty field as mandatory vs explicitly setting display as true.
const gform = querySelectorShadowDom.querySelectorAllDeep('sn-form-data-connected')[0]?.nowRecordFormBlob?.gForm //use g_form when calling from client script
gform.setDisplay("description", true)
console.log(gform.getFieldNames().filter(n => gform.isVisible(n)))
gform.setDisplay("description", false)
console.log(gform.getFieldNames().filter(n => gform.isFieldVisible(n)))as above:
