User Interface Development practice questions

Write a client script that adds a button dynamically.

Why wrong: While possible, it is not the recommended approach; UI Actions are designed for this.

Modify the form layout to include a button widget.

Why wrong: Form layout does not support adding custom buttons.

Configure a UI Policy.

Why wrong: UI Policies are for field visibility and behavior, not buttons.

Create a UI Policy on the incident table with a client script that shows the button conditionally.

Why wrong: Incorrect. UI Policies modify field properties (e.g., visibility, mandatory) based on conditions, but they cannot create new buttons. They are not designed to add UI elements like custom buttons.

Create an Access Control Rule (ACL) on the incident table and attach a client script.

Why wrong: ACLs control access, not UI elements.

Create a Business Rule on the incident table that injects a button via server-side code.

Why wrong: Business Rules run server-side and cannot directly modify client UI.

The server script expects the parameter in a different scope variable, like $scope.c.data.item.

Why wrong: The server script reads from $scope.c.data, which matches.

The $scope.c.data assignment is incorrect; it should be $scope.data.

Why wrong: $scope.c is correct for client-server data in Service Portal.

The client controller is not allowed to set $scope.c variables.

Why wrong: Client controllers can set $scope.c variables.

Pass a role check from the server script to the client controller via widget options.

Why wrong: Widget options do not enforce security.

Write an Access Control Rule (ACL) on the widget's table to restrict access.

Why wrong: ACLs control data access, not UI widget visibility.

Create a UI Policy on the portal table that hides the widget based on user roles.

Why wrong: UI Policies do not apply to Service Portal.

Create a form section and set its condition via the 'Conditional' property.

Why wrong: Form sections cannot be conditionally displayed based on field values.

Write a Client Script that shows a message when state changes to Closed.

Why wrong: Requires scripting; not the low-code approach.

Use a UI Macro with a condition that checks the state field.

Why wrong: UI Macros require scripting and are not low-code.

The widget template is not bound to the correct scope variable.

Why wrong: Binding issues could occur, but the primary issue is missing promise handling.

The client controller should use $scope.server.update() instead of $scope.server.get().

Why wrong: $scope.server.update() is not a valid method.

The server script is not allowed to modify data from a widget server script.

Why wrong: Widget server scripts can modify data.

Create a new widget instance on the 'loginpage' widget slot.

Why wrong: The login page is a special page; widget slots are not used.

Add a widget option to the login widget to inject custom CSS.

Why wrong: Widget options are for runtime data, not CSS injection.

Set the 'login.css' property in sys_properties to a custom stylesheet URL.

Why wrong: There is no such sys_property.

They run on the server and are called via server-side includes.

Why wrong: Client controllers run in the browser.

They must define a $scope variable explicitly to bind data to the template.

Why wrong: $scope is automatically available via AngularJS.

The addQuery method syntax is incorrect; it should use a condition string.

Why wrong: addQuery('active', true) is valid syntax.

The while loop uses next(); it should use hasNext() instead.

Why wrong: next() is correct to iterate.

GlideRecord requires an initialize() call before query.

Why wrong: GlideRecord constructor initializes the object.

Nothing happens because newValue equals 'Network' which passes the empty check.

Why wrong: newValue is not empty, so the condition fails and the setValue runs.

An error occurs because setValue cannot be called with a string.

Why wrong: setValue accepts a string.

The short_description is cleared.

Why wrong: The script sets a value, not clears.

The server script fails due to a mandatory field not being provided, but the error is not logged.

Why wrong: The developer checked logs and saw no errors.

The server script uses data.success = true; but the client controller does not read it.

Why wrong: The client controller receives data from the server.

The widget has a Client Script that conflicts with the server script.

Why wrong: Client Scripts are not used in Service Portal widgets.

Modify the form layout to remove the field.

Why wrong: Form layout is static and does not support dynamic hiding based on conditions.

Use a catalog client script to hide the field.

Why wrong: Catalog client scripts are for client-side actions but UI Policy is the recommended approach for visibility.

Write a client script to set the field's display property to false on load.

Why wrong: Client scripts can hide fields but are less efficient than UI Policies for simple visibility control.

The table's ACL denies read access to the user.

Why wrong: ACL issues typically produce a different error or empty result, but it's less likely if other widgets show data.

The widget's client script has a syntax error.

Why wrong: Client script errors affect user interactions, not the initial data load.

The portal page is not configured to include the widget.

Why wrong: If the widget renders, it is included on the page.

The field's ACL does not allow the user to see it.

Why wrong: ACLs do not control mandatory enforcement.

The form is in a different ordering of UI Policies.

Why wrong: Order matters but not as likely as the client-side execution setting.

A client script is overriding the mandatory property.

Why wrong: A client script could override, but the most common cause is the UI Policy not running client-side.

The user does not have read access to the referenced table.

Why wrong: ACLs would block the entire field, not just the list.

The field is read-only and prevents searching.

Why wrong: Read-only fields can still show dropdowns but may appear disabled.

The field's dictionary entry does not have a reference table specified.

Why wrong: If the table were missing, the field would not work at all.

Use $rootScope to make data globally available.

Why wrong: Global scope is not recommended and can cause conflicts.

Use $scope to store data in the client controller.

Why wrong: $scope is available but not the intended pattern; 'c' is preferred.

Create a custom AngularJS factory to manage data.

Why wrong: Factories are for shared services, not for widget-specific data binding.

UI Script (sys_ui_script)

Why wrong: UI Scripts contain reusable JavaScript, not CSS.

Portal Theme (sp_theme)

Why wrong: Portal themes are for Service Portal, not UI16.

Branding (sys_brand)

Why wrong: Branding includes logos and colors but does not fully theme the interface.

The form is not refreshing after submission.

Why wrong: The form automatically refreshes when the record is opened again.

The business rule is set to run asynchronously.

Why wrong: Asynchronous rules still update the record; the value should persist.

A UI Policy is hiding the field.

Why wrong: Hidden fields still contain values; they just aren't visible.

Check the browser's HTML source for the macro's placeholder.

Why wrong: This can help but is not the most direct initial step.

Ensure the UI Macro is in the global scope.

Why wrong: Scope issues are possible but syntax errors are more common.

Verify that all referenced UI Scripts are loaded.

Why wrong: UI Scripts are not typically used in UI Macros; macros use Jelly.

The script is missing a semicolon after the setValue statement.

Why wrong: Missing semicolons do not prevent execution.

g_form is not available in the onChange client script.

Why wrong: g_form is available in all client script types.

The script runs before the new value is assigned to the field.

Why wrong: The onChange event fires after the value changes.