Troubleshooting Scenario Questions

The assignment group field is read-only on the form but can be set via business rule

Why wrong: Read-only status on the form does not prevent business rules from setting the field value; therefore this is not a cause.

The business rule is set to run only in the global scope

Why wrong: The scope of the business rule does not affect its ability to run on update; this is not a likely cause.

Change the 'NameID format' from 'Unspecified' to 'EmailAddress' in the SAML2 configuration

Why wrong: The NameID format defines the XML format of the subject, not the ServiceNow field to match.

Create an LDAP integration to automatically create ServiceNow users from the identity provider

Why wrong: This is a separate process; the immediate issue is mapping the incoming SAML username to the existing user record.

Update all ServiceNow user records to have the 'User ID' field populated as full email addresses

Why wrong: Changing the User ID to email format would be a large data migration and may affect other integrations.

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 using a deprecated API.

Why wrong: Incorrect. The API for hiding fields (g_form.setVisible) is not deprecated.

The script is not running due to a missing 'Run As' role.

Why wrong: Incorrect. Client scripts do not have a 'Run As' role; that is a server-side script feature.

The field is not part of the application scope.

Why wrong: Incorrect. Client scripts can access any field on the form regardless of the field's scope.

Add an index on the cmdb_ci table for the location field and use an efficient query.

Why wrong: Plausible but still synchronous; performance gain may be insufficient.

Move the logic to a scheduled job that runs every hour instead of on every update.

Why wrong: Incorrect: Changes functionality by delaying updates, likely unacceptable.

Convert the GlideRecord query to use GlideRecordSecure to limit access.

Why wrong: Incorrect: GlideRecordSecure is for security, not performance.

The UI policy is set to 'Run on mobile' but the script is incompatible.

Why wrong: Incompatible script would likely cause an error, not silent failure.

The field is not available on the mobile form.

Why wrong: If the field is not present, the policy might not apply, but the most common reason is the run option.

The mobile app uses a different table.

Why wrong: Mobile app typically uses the same table but a different user interface.

OAuth token for LDAP is expired

Why wrong: LDAP does not use OAuth; it uses bind credentials.

LDAP attribute mapping does not match target fields

Why wrong: Attribute mapping issues cause field errors, not import failure.

LDAP server is unreachable

Why wrong: Connectivity is a basic check, but it is not specific to LDAP import configuration.

Check the business rule order.

Why wrong: Order is relevant for conflicting rules but not a primary diagnosis step.

Run the business rule from the context menu.

Why wrong: Business rules cannot be executed manually.

Check if the table is locked.

Why wrong: Table locks affect records, not business rule execution.

The 'change_request' table is locked for data imports.

Why wrong: Table locking is not a common reason; it's more likely a validation issue.

The user's role is not recognized when using SOAP web services.

Why wrong: The user's role is recognized; ACLs are evaluated correctly.

The SOAP message uses a different namespace.

Why wrong: A namespace mismatch would cause a parsing error, not a failure to insert.

Review the syslog for error messages.

Why wrong: While helpful, this is not the most efficient first step; Studio's debugger is more direct.

Check the ACLs on the table.

Why wrong: ACLs do not affect client script execution.

Add a gs.log() statement to the server-side code.

Why wrong: Client scripts run client-side; server-side logging won't help.

The section's 'Visible' checkbox in the form layout must be unchecked and then controlled by the UI Policy

Why wrong: There is no 'Visible' checkbox for sections in form layout.

The UI Policy must be set to 'Run for all users' and the section must be assigned a 'visible' attribute

Why wrong: UI Policies can be set to run for all users, but they still cannot hide sections.

The UI Policy order is too low; it should be set to a higher priority number

Why wrong: Order affects evaluation, but even the highest priority UI Policy cannot hide a section.

Use a database view to join the import set and incident table on the external_id field.

Why wrong: Incorrect: A database view is read-only and does not perform data imports or updates.

Modify the existing transform map to use 'update' action and set coalesce on the sys_id field.

Why wrong: Incorrect: The sys_id formats differ, so coalesce on sys_id would not match records.

Increase the scheduled import frequency to overwrite the records.

Why wrong: Incorrect: This does not fix the matching problem; it would just run more often with the same issue.

Check the client script that may be hiding the field.

Why wrong: Client scripts could hide it, but the first step is to verify the field exists on the form.

Check the ACLs for the 'Cost Center' field.

Why wrong: ACLs control data access, not visibility.

Check the role requirements for the field.

Why wrong: Roles affect access, but if the field is not on the form, it won't show.

Use a parent widget that calls three child widgets

Why wrong: Incorrect: Parent-child setup can still lead to cascading failures if parent fails.

Use a widget that loads data in parallel with error handling

Why wrong: Incorrect: Despite parallel loading, if the single widget has a critical error, all data may be lost.

Use a single widget that fetches all data sequentially

Why wrong: Incorrect: Sequential fetching means one failure stops all data loading.

Wrap the script in a try-catch block and log the error then return

Why wrong: This would hide the error and the workflow would still not start.

Change GlideRecord('task') to GlideRecord('change_request')

Why wrong: This would work but is unnecessarily complex; current already holds the record.

Add a check if (task.isValidRecord()) before accessing cmdb_ci

Why wrong: This would prevent the error but would not fix the logic; the CI would not be found.