Core Application Development practice questions

Create a Client Script that runs on load to update related records.

Why wrong: Client Scripts run on the client and cannot perform server-side updates.

Create an ACL to automatically propagate changes.

Why wrong: ACLs control access, not data propagation.

Create a UI Policy that sets the location field on related records.

Why wrong: UI Policies only control field attributes on the form.

Use the global scope to avoid access restrictions.

Why wrong: Global scope is not recommended for custom applications; it can cause conflicts.

Use a scope name that is already in use to leverage existing configurations.

Why wrong: Scope names must be unique.

Create the scope and later change the name if needed.

Why wrong: Scope name cannot be changed after creation.

Use Flow Designer to create a flow that sends an email.

Why wrong: Flow Designer can be used but is more complex than a simple notification.

Write a Business Rule that calls the email utility.

Why wrong: Possible but not the standard approach; notifications are preferred.

Create an ACL with email action.

Why wrong: ACLs control access, not email notifications.

Create a Database View that filters out Completed records.

Why wrong: Database Views are for reporting, not for preventing updates.

Create a Client Script that sets the field to read-only when status is Completed.

Why wrong: Client Scripts can only set read-only on the form, but updates via other channels are not blocked.

Create a UI Policy to disable the entire form when status is Completed.

Why wrong: UI Policies only control form behavior, not server-side updates.

Multi Line Text

Why wrong: Multi Line Text is for long text, not file uploads.

Single Line Text

Why wrong: Single Line Text is for short text input, not file uploads.

Checkbox

Why wrong: Checkbox is for boolean values.

Create a 'List' field type and set the table to sysapproval_approver.

Why wrong: 'List' is not a valid field type in ServiceNow.

Create a 'Reference' field and set the table to 'task' and the reference field to 'sysapproval_approver'.

Why wrong: The reference field should point to the table, not a field.

Create a 'Choice' field and populate it with sysapproval_approver values.

Why wrong: Choice fields are for static lists, not dynamic references.

The job's condition script has a syntax error.

Why wrong: A syntax error would cause the job to fail, but it would still attempt to run and log errors.

The 'sys_updated_on' field is not being updated.

Why wrong: The sys_updated_on field is not relevant to job execution.

The job condition is set to 'false' so it never triggers.

Why wrong: If the condition is false, the job still runs but the condition script returns false; however, the job itself runs.

Single Line Text

Why wrong: Single Line Text is for single text input.

Radio Button

Why wrong: Radio Button allows only one selection.

Select Box

Why wrong: Select Box allows only one selection.

From the Business Rules list, right-click and select 'New'.

Why wrong: Right-click on list does not have 'New' option.

Type 'business_rule.do' in the navigator filter.

Why wrong: This opens the list but does not create a new record.

Create a Client Script and convert it to a Business Rule.

Why wrong: There is no conversion functionality.

ACLs are evaluated on the client side.

Why wrong: ACLs are evaluated server-side.

ACLs are only applicable to system tables.

Why wrong: ACLs can be applied to custom tables as well.

On submit

Why wrong: On submit is not a UI Policy type.

On delete

Why wrong: On delete is not a UI Policy type.

On query

Why wrong: On query is not a UI Policy type.

The script should use 'current' instead of 'gr' to update records.

Why wrong: The script is intended to update multiple records, not just the current one.

The script has a syntax error: missing semicolon after the while loop.

Why wrong: The while loop does not require a semicolon after the closing brace.

The script does not commit the changes because it uses 'gr.update()' instead of 'current.update()'.

Why wrong: gr.update() commits changes to the database.

The user will be prompted for credentials.

Why wrong: ACLs do not prompt for credentials.

The user will be allowed because the condition is ignored for write operations.

Why wrong: Condition is always evaluated.

The user will be allowed because the script sets answer = true.

Why wrong: The script only runs if the condition is true.

The event name is misspelled in the gs.eventQueue call.

Why wrong: If the event name were incorrect, the notification would not trigger, but the developer verified the event exists.

The notification is set to 'Inactive'.

Why wrong: The developer verified the notification is active.

The employee's email address is not set in sys_user.

Why wrong: If the email were missing, the notification would still be sent but fail delivery; the question says the email is not being sent at all.

The Business Rule is set to run after the record is saved, so changes are overwritten.

Why wrong: Before update runs before save, so changes are persisted.

The condition 'current.u_status.changesTo("Retired")' is incorrect.

Why wrong: The condition is correct for detecting status change.

The Business Rule runs after update instead of before update.

Why wrong: The developer set it to before update, which should work.

Create a UI Policy with a condition and a UI message.

Why wrong: UI Policies can show messages but also affect field states, which is overkill for just a warning.

Create a Business Rule that uses gs.addErrorMessage().

Why wrong: gs.addErrorMessage() runs server-side and returns the message on the next server interaction, not instantly client-side.

Create a Data Policy for the field and set a warning message.

Why wrong: Data Policies are for enforcing mandatory/read-only, not for displaying warnings.

There is a script error that is being ignored because the Business Rule is set to 'true' for 'Run asynchronously'.

Why wrong: Asynchronous rules still log errors; a script error would prevent the update.

The Business Rule runs in a separate transaction and the update is rolled back.

Why wrong: Business Rules run in the same transaction as the triggering record update; no rollback occurs unless there is an exception.

The user running the script does not have write access to the related table.

Why wrong: If the script runs with the user's rights and they lack access, an error would typically occur, not silent failure.

The ACL is cached and users need to log out and back in for changes to take effect.

Why wrong: ACL changes take effect immediately; caching is not a typical issue.

The condition script returns 'true' for users in the group but does not return 'false' for others, so the ACL defaults to 'no decision' and access is allowed.

Why wrong: ACLs that do not return true default to deny (no match), not allow. This would block access.

The ACL is set to 'Inactive' so it does not apply, leaving access open.

Why wrong: If inactive, the ACL is not evaluated; but the question implies the scripted ACL is being considered but not working.