Core Application Development practice questions

Create a Database View that filters out Completed records.

Why wrong: A Database View does not prevent updates to the base table; it only filters records in the view. Updates can still be made via other means.

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

Why wrong: Client Script only affects the UI; it can be bypassed by direct API calls or database operations.

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

Why wrong: UI Policy is client-side only and can be circumvented; it does not provide server-side enforcement.

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 is set to 'Inactive'.

Why wrong: This is incorrect. If the job is set to 'Inactive', it will not run at all—the scheduler will not trigger it, and no entry will appear in the job history. The stem states the job runs, so an inactive job cannot be the cause.

The flow trigger is set to 'On Created' but the incident already existed

Why wrong: The trigger being 'On Created' would cause the flow to run only when a new incident is created, but if the incident already existed, the flow wouldn't trigger at all—not a silent failure.

The flow is using a 'Lookup Record' instead of 'Update Record'

Why wrong: Using a 'Lookup Record' would retrieve a record, not update it; this would likely be noticeable as the flow wouldn't modify the record, but the flow would still run without errors—this is a possible cause but less likely than scope permissions.

The 'Update Record' action is referencing the wrong table

Why wrong: Referencing the wrong table would likely cause an error (e.g., table not found) or update a different table; if it runs without error, it would update the wrong record, not silently fail to update the correct one.

Change the trigger order from 'before' to 'after'.

Why wrong: Changing order doesn't fix the condition issue.

Remove the condition and let the script run always.

Why wrong: That would make the problem worse.

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: Using global scope is not a best practice as it reduces control and increases risk of unintended modifications.

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

Why wrong: Using a scope name that is already in use is not allowed; each scope must be unique.

Create the scope and later change the name if needed.

Why wrong: Creating a scope and later changing the name is not recommended as scope names are typically immutable after creation.

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

Why wrong: Flow Designer can send emails, but the question asks which component should be configured to *trigger* the notification when a new incident is created. A flow requires an explicit trigger—such as a "Record Created" event on the Incident table—to initiate the email action; without configuring that trigger, the flow will not fire automatically. This option is tempting because Flow Designer is a powerful tool for automating email notifications in many scenarios, and it would be the correct choice if the requirement were to send a custom email with complex logic or data transformations beyond a simple outbound 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.

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.

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.

Navigate to Maintain Items, then Create New, then Add Variables, then Set Category and Details, then Submit

Why wrong: This is incorrect because variables should be added after setting the category and details, as variables may depend on the category or other item properties.

Set Category and Details, then Navigate to Maintain Items, then Create New, then Add Variables, then Submit

Why wrong: This is incorrect because you cannot set category and details before navigating to the correct module and creating the item; the item does not exist yet.

Navigate to Maintain Items, then Add Variables, then Create New, then Set Category and Details, then Submit

Why wrong: This is incorrect because you must create the catalog item before adding variables, as variables are properties of the item.

Delete ACL: Grants permission to run server-side scripts.

Why wrong: Incorrect — Delete ACLs allow removal of records, not script execution; Execute ACLs control scripts.

Execute ACL: Grants permission to remove records.

Why wrong: Incorrect — Execute ACLs allow running scripts or actions; record removal is handled by Delete ACLs.

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.