Video summary

Platform Academy — Mobile Client Scripting with Input Form Screens

Main summary

Key takeaways

Technology

Summary of Technological Concepts / Product Features (Mobile Client Scripting)

What problem it solves

  • Prior to the Xanod release, on mobile input form screens, selecting inputs did not allow dynamically autofilling/prepopulating other fields.
  • Example: if a user chose assignment, the related assignment details wouldn’t populate automatically—forcing users to manually fill long questionnaires.

What “Mobile Client Scripting” does

  • Autofills one or more form inputs based on user input.
  • Implemented using:
    • Client scripts (via mobile UI rule actions)
    • Mobile callable script includes (for more complex logic/data lookup)
  • Adds real-time form validation messaging:
    • Scripted info and error messages can display during form entry so users can correct before submit.

Implementation Approach (How it’s built)

Uses UI rules as the entry point

  • Mobile client scripting leverages the platform’s existing UI rules feature.
  • Introduced a new UI rule action type: “run client script”
    • Conceptually similar to Now platform client scripts, but mobile-specific behaviors apply.

Only works on field change (“onchange”)

  • Mobile client scripts are triggered using onchange only.
  • They do not work for onload or other user actions.
  • UI rule conditions can narrow triggering:
    • If the UI rule condition is empty, it can trigger broadly (potentially inefficient).
    • Use a condition like “field val changes” to target specific fields.

Key APIs for mobile client scripting

1) M form API

Provides methods to manage mobile form input values and messages.

  • Used for operations like:
    • Getting an input value
    • Setting an input value
    • Displaying info/error messages
  • Supports common input types (examples mentioned: boolean, choice, number, reference, string, etc.).
  • The speaker compared it to gForm; mForm is more constrained and includes five key methods (shown in the demo rather than fully enumerated).

2) Mobile Script Include Caller

Enables calling server-side script includes from mobile client scripting.

  • Similar idea to GlideAjax:
    • Provide script include name + function name
    • Pass parameters
    • Receive results via a callback
  • Requirements/constraints highlighted:
    • The script include must be marked Mobile callable
    • It must extend Abstract Mobile Callable Include (cannot be replaced/changed arbitrarily)
    • Script include access requires appropriate roles (the demo mentioned needing a specific role setup).

Demo Use Cases Covered

Use case A: Autofill a reference field (naive “mapping” approach)

  • Auto-populated Assigned To based on Assignment Group.
  • Steps emphasized:
    • Create a UI rule with condition using “ value changes” (e.g., assignment group changes)
    • In the UI rule action, use run client script
    • Use M form get value to read the Assignment Group
    • Use M form set value to set Assigned To (using sys_id/CIs IDs since both fields are references)
  • Limitation shown:
    • Works only if you hardcode a limited mapping (e.g., only one group → one user manager). Large enterprises need a dynamic solution.

Use case B: Dynamic autofill using a mobile callable script include

  • Implemented “Assignment group → group manager → assigned to”
  • Script include logic:
    • Read assignment group parameter
    • Look up the group in CI user group table
    • Return the group’s manager sys_id (or null if no manager)
  • Mobile client side:
    • Create new Mobile Script Include Caller
    • Call function (e.g., getGroupManager)
    • Use returned manager value to set Assigned To
  • Result:
    • Selecting different assignment groups updates Assigned To dynamically.

Use case C: Validation messaging (info vs error)

  • If returned manager is null:
    • Show an info message: “Chosen group has no manager assigned”
  • If the situation is considered destructive/critical:
    • Show an error message instead

Use case D: “Surprise” UX tweak—loading/simmer effect

  • Script includes may take ~1–2 seconds, so the UI might appear “stuck.”
  • Demo used M form “set affected inputs” API:
    • Apply a shimmer/loading effect to specific inputs while waiting for script include results.
    • Example mentioned affecting multiple fields to indicate background processing.

Troubleshooting & Best Practices (Listed)

  • Only one “run client script” per UI rule
    • If you need multiple client scripts, create separate UI rules.
  • Ensure trigger is onchange
    • If nothing happens, check you didn’t use onload.
  • Use conditions to avoid inefficient triggering
    • Example: condition like assignment group val changes to trigger only when relevant field changes.
  • Do not change the onchange function signature
    • The template inserted by “run client script” must remain intact.
  • Mobile callable script include requirements
    • Must be Mobile callable
    • Must extend Abstract Mobile Callable Include
  • General scripting discipline:
    • Scripts should be efficient
    • Double-check typos / correctness when debugging

Q&A Highlights

Does this apply to MESP pages?

  • Mentioned as only supported for native input forms.
  • If a form is in MESP view, it may render in a web view, but mobile client scripting itself is not supported for MESP pages.

Meaning of “new value” in val changes

  • The “new value” corresponds to the updated value the user just entered/selected.

What decides whether onchange fires per field

  • Depends on the condition:
    • Empty condition can cause firing broadly.
    • Using a specific val changes on a particular field scopes it.

Main Speakers / Sources

  • Sharon Barnes (Platform outbound product manager; event host)
  • Sana (Senior Product Manager, mobile platform team)
  • Tal (Software Engineer, mobile back end team)

Source referenced/used in demos: IPSM Mobile Agent app (with minor tweaks for the presentation)

Original video