User Interface Development practice questions

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.

Create a UI Action on the incident table with a client script and set the 'Show insert' condition.

Why wrong: UI Actions are for form buttons but not ideal for conditional display based on client script logic.

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.

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.

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.