We’re rolling out mobile access for our field technicians and I’m discovering that form configurations that work perfectly on desktop are causing confusion on mobile devices. The mobile form layout seems to handle UI policies differently, and some client scripts don’t fire as expected.
For example, our incident form has conditional sections that expand/collapse based on category selection. On desktop, this works smoothly with UI policies. On mobile, the sections either don’t collapse or the timing is off, causing users to scroll through irrelevant fields.
I’m curious about others’ experiences with mobile form UX configuration. What are the main challenges you’ve faced with UI policy differences between platforms? How do you handle client script compatibility when the same form needs to work on both desktop and mobile? Are there specific design patterns that work better for mobile, or do you maintain separate form configurations entirely?
UI policies behave differently on mobile because the rendering engine is different. Desktop uses the standard ServiceNow UI, while mobile uses a native wrapper with its own interpretation of UI policies. Client scripts are even trickier - some GlideForm methods work differently or not at all on mobile. We maintain a compatibility matrix documenting which scripts work on which platforms. For critical functionality, we use server-side business rules instead to ensure consistency.
The client script compatibility issue is real. Mobile doesn’t support all the same JavaScript APIs as desktop. We’ve found that g_form methods generally work, but DOM manipulation doesn’t. Our solution was to create a utility script include that detects the platform and adjusts behavior accordingly. For mobile, we keep interactions simple - basic field visibility, mandatory rules, and value population. Complex validation happens server-side.
Great discussion topic! I’ve been working with mobile ServiceNow implementations for three years and have learned a lot about the challenges you’re describing. Let me share insights on all three areas:
Mobile Form Layout Challenges:
The fundamental issue is that mobile and desktop use different rendering engines. Mobile uses a card-based layout optimized for vertical scrolling, while desktop uses traditional form sections. This creates several problems:
- Sections that look organized on desktop become long scrolling lists on mobile
- Multi-column layouts collapse to single column, changing the visual hierarchy
- Embedded lists and related lists perform poorly on mobile
- Field groups that make sense on desktop feel cluttered on small screens
Best practice: Design a simplified mobile form view with 40-60% fewer fields than desktop. Use the Mobile Studio to create mobile-specific layouts rather than trying to adapt desktop forms.
UI Policy Differences:
UI policies execute differently on mobile for several reasons:
- Mobile evaluates policies on form load but not always on field change
- Timing issues with async field updates cause policies to miss trigger conditions
- Complex nested conditions often fail silently on mobile
- Policy ordering matters more on mobile than desktop
Our approach: Keep mobile UI policies extremely simple. Use only basic conditions (field equals value) and avoid complex AND/OR logic. For your conditional sections, instead of expand/collapse, use complete show/hide of entire sections. Test thoroughly on actual devices, not just browser simulation.
Client Script Compatibility:
This is the biggest pain point. Mobile supports a subset of client script functionality:
- Basic g_form methods work (getValue, setValue, setVisible, setMandatory)
- Advanced methods like getReference and getOption often fail
- DOM manipulation via getElement doesn’t work
- Some timing-dependent scripts execute in different order
- Catalog client scripts have even more limitations
Strategy: Create a platform detection utility and branch your logic. For mobile, keep scripts minimal and rely more on server-side business rules. Consider using Flow Designer for complex logic that needs to work consistently across platforms.
Recommended Architecture:
We now maintain separate form configurations:
- Desktop: Full-featured forms with all fields and complex interactions
- Mobile: Streamlined forms with essential fields only
- Shared: Business rules and workflows that work server-side
This separation increases maintenance overhead but provides much better UX. Users appreciate forms optimized for their context rather than a compromise that works poorly everywhere.
The key insight: Stop thinking of mobile as “desktop on a smaller screen.” It’s a different use case with different user needs, different technical constraints, and different interaction patterns. Design accordingly.
Mobile forms definitely require a different approach. We learned the hard way that desktop-optimized forms don’t translate well. The main issue is screen real estate - what fits comfortably on a desktop monitor becomes overwhelming on a phone. We now design mobile-first, then adapt for desktop. For conditional sections, we use simpler show/hide logic on mobile rather than complex expanding sections.
One challenge nobody mentions enough is network reliability. Desktop users have stable connections, but mobile users might be in areas with poor coverage. This affects how UI policies and client scripts perform. We’ve had to add more aggressive caching and offline capabilities. Also, reference field lookups that are instant on desktop can timeout on mobile. Consider using choice lists instead of reference fields where possible on mobile forms.