©️HackNow Call/WhatsApp: +91 8984988593 Visit Us: [Link]
in
️HackNow Call/WhatsApp: +91 8984988593 Visit Us: [Link]
Question: An 'itil' user reports they cannot see a UI
Action on an Incident form, but you've confirmed the
UI Action's condition is met. Why is it not visible?
✔ Answer:
• Use the Security Debugger (System Security >
Debugging > Debug Security Rules) to see which ACLs are
preventing access.
• Check the table-level Access Control Lists (ACLs) for
the incident table. The user needs write access to the
record for a UI Action that modifies it (like "Assign to me")
to appear.
• Verify that no other overriding UI Action with a higher
Order value is hiding the one in question.
• Ensure the UI Action is marked as Active and is
configured to appear on the correct form view (e.g., "Form
button" or "Form context menu").
Logic: The visibility of a UI Action is controlled by its own
conditions and the user's permissions on the record itself,
which are governed by ACLs. A user cannot perform an action if
they don't have the underlying rights to modify the record.
Common Pitfall:
• Focusing only on the Condition field of the UI Action and
forgetting about table ACLs.
• Assuming a user's role (like 'itil') automatically grants
write access without checking for custom ACLs that might
be overriding it.
• Not using the Security Debugger, which is the primary tool
for diagnosing permission issues.
©️HackNow Call/WhatsApp: +91 8984988593 Visit Us: [Link]
Question: You created a custom Service Portal widget
to display a list of approvals. Clicking a button on this
widget is supposed to refresh a separate "My
Approvals" widget on the same page, but nothing
happens.
✔ Answer:
• Ensure both widgets are communicating using the
$rootScope.$broadcast() and $scope.$on() methods.
Verify the event name used in both is identical.
• Alternatively, for watching record changes, use the
[Link]($scope, "sysapproval_approver",
"state=requested", function(response) { ... }); method in
the receiving widget.
• Check the browser's developer console (F12) for any
JavaScript errors in the widget's Client Controller.
• Confirm that $rootScope and spUtil are properly injected
into the widget's client script function.
Logic: Service Portal widgets exist in isolated AngularJS
scopes. Direct communication is not possible; they must
communicate through a shared parent scope ($rootScope) or
use built-in Service Portal utilities like spUtil that are designed
for this purpose.
Common Pitfall:
• Trying to directly call a function from one widget's client
controller in another.
• A typo or case-sensitivity mismatch in the broadcast/listen
event name.
• Forgetting to inject $rootScope into the client script
function function($scope, $rootScope, spUtil) { ... }.
Book a One-on-One Call: Facing challenges with ServiceNow administration, scripting, integrations, or real-
world use cases? Book a one-on-one call for expert guidance on streamlining administration, mastering
scripting, seamless integrations, and solving scenario-based challenges. Click here to schedule!
️HackNow Call/WhatsApp: +91 8984988593 Visit Us: [Link]
Question: You wrote an Inbound Email Action to
create a custom task record from an email, but emails
sent to the instance are being ignored and no task is
created. You've confirmed the recipient email address
is correct.
✔ Answer:
• Navigate to System Logs > Emails and find the specific
incoming email. Check its state and review any error
messages in the log.
• Verify the Order of your Inbound Action. Another action
with a lower order number might be matching the email
and has the "Stop processing" checkbox checked.
• Check the Condition on your Inbound Action. Ensure it
correctly evaluates against the incoming email's subject,
body, or headers. Add [Link]() statements to test the
condition.
• Make sure the Type of the action (e.g., 'New', 'Reply')
matches the type of email being sent.
Logic: The system processes inbound email actions based on
their Order value, from lowest to highest. If a matching action is
found and is configured to stop processing, no subsequent
actions will be run for that email.
Common Pitfall:
• Setting the Order too high, allowing a more generic, lower-
order rule to run first.
• Having a condition that is too restrictive or has a mistake
in it.
• Not checking the Email Log, which is the most critical step
for diagnosing any inbound email issue.
Book a One-on-One Call: Facing challenges with ServiceNow administration, scripting, integrations, or real-
world use cases? Book a one-on-one call for expert guidance on streamlining administration, mastering
scripting, seamless integrations, and solving scenario-based challenges. Click here to schedule!
©️HackNow Call/WhatsApp: +91 8984988593 Visit Us: [Link]
Question: A Flow you built to process records using a
"For Each" loop runs very slowly and sometimes times
out when it has to process a large number of records.
✔ Answer:
• Avoid using the "Look Up Record" action inside of the
"For Each" loop. Instead, use one "Look Up Records"
action before the loop to gather all necessary data into a
list.
• Check the Flow execution details to identify which specific
action or step is causing the bottleneck.
• For very complex data transformations, consider replacing
multiple built-in actions inside the loop with a single
custom Action that performs the logic via script, which
is often more performant.
• Ensure that any "Wait for condition" steps inside the loop
have a reasonable timeout and are absolutely necessary.
Logic: Each action inside a Flow Designer loop adds significant
processing overhead and often initiates a separate database
transaction. Performing a single, bulk query before the loop is
far more efficient than running hundreds of individual lookups
within it.
Common Pitfall:
• Treating a "For Each" Flow logic block like a standard code
for loop without considering the performance cost of each
action.
• Performing one record lookup at a time inside a loop
instead of a single bulk query beforehand.
• Failing to use Flow reporting and execution details to
diagnose performance bottlenecks.
️HackNow Call/WhatsApp: +91 8984988593 Visit Us: [Link]
Question: A field on the Incident form is unexpectedly
read-only for 'itil' users. You've checked every Client
Script, but none of them are causing it. What is the
likely cause?
✔ Answer:
• Check all UI Policies that are active on the incident table.
A UI Policy can make fields read-only, mandatory, or
hidden without any visible script.
• Use the Field Watcher utility by right-clicking the field's
label and selecting "Watch Field". This will show you in
real-time what scripts or policies are acting on the field
when the form loads.
• Verify the conditions on the UI Policies. It's likely a
policy's condition is being met for 'itil' users, triggering a
UI Policy Action to make the field read-only.
• Ensure that the "Reverse if false" checkbox on the UI
Policy is set correctly to undo the action when the
condition is no longer met.
Logic: Both Client Scripts and UI Policies execute on the
client-side to control form behavior. It is a common mistake to
debug only one while forgetting the other. UI Policies are often
the source of "no-code" form changes that can be hard to track
down without the right tools.
Common Pitfall:
• Only looking at Client Scripts and completely forgetting to
check UI Policies and their associated UI Policy Actions.
• Not knowing about or using the "Field Watcher" utility,
which is the fastest way to debug field state changes.
• Having multiple conflicting UI Policies that act on the
same field, leading to unpredictable behavior.
Need Help? Join Our WhatsApp Community: Struggling with ServiceNow administration, scripting,
integrations, or real-world use cases? Don’t worry! Join our WhatsApp community for real-time support,
tips, and advice from experts and peers on the same journey. You’re not alone—we’re here to help you
succeed. Click here to join the community!
©️HackNow Call/WhatsApp: +91 8984988593 Visit Us: [Link]
Question: Your script within a scoped application fails
with a security error when it tries to read records from
a table in a different scope (e.g., a custom HR table).
✔ Answer:
• Navigate to the record for your scoped application under
System Applications > My Company's
Applications.
• In the related lists at the bottom, find the "Application
Cross-Scope Access" tab and check if a record exists for
the target table you need to access.
• If no record exists, you must create one. Set the Source
Scope to your application, the Target Scope to the
application that owns the table, the Target Name to the
table's name (e.g., x_mycorp_hr_table), and the
Operation to read.
• Ensure the Status of the cross-scope privilege record is
set to Allowed.
Logic: Scoped applications are designed to be secure
sandboxes. By default, they are not allowed to access resources
(like tables or script includes) from other application scopes.
Access must be explicitly granted by creating a Cross-Scope
Privilege record.
Common Pitfall:
• Assuming that scripts in a scoped app have the same
global access rights as scripts in the global scope.
• Forgetting that table access between scopes must be
explicitly granted for all operations (read, write, create,
delete).
• Misconfiguring the cross-scope access record with the
wrong status, operation, or target table name.
Need Help? Join Our WhatsApp Community: Struggling with ServiceNow administration, scripting,
integrations, or real-world use cases? Don’t worry! Join our WhatsApp community for real-time support,
tips, and advice from experts and peers on the same journey. You’re not alone—we’re here to help you
succeed. Click here to join the community!
️HackNow Call/WhatsApp: +91 8984988593 Visit Us: [Link]
Question: You wrote a GlideAjax call from a Client
Script to fetch manager info, but it returns undefined.
Why?
✔ Answer:
• Always use
getXMLAnswer() for return values, as getXML() requires
manual XML parsing.
• Confirm that the Script Include is set to
Client Callable.
• The Script Include must use
return answer; to send back a value, not [Link]().
Logic: The core causes are asynchronous behavior and
incorrect callback usage.
Common Pitfall:
• Using
getXML() but expecting raw text.
• Not marking the Script Include as "Client Callable".
• Using
[Link]() instead of return in the server-side method.
Question: You've used Document Generation
(DocGen) from a Flow to generate a PDF invoice, but
either the data is missing or the file doesn't attach.
Why?
✔ Answer:
• Check if the Document Template has the correct
placeholders.
• Verify the Flow uses the 'Generate Document' action and is
pointing to the correct table.
©️HackNow Call/WhatsApp: +91 8984988593 Visit Us: [Link]
• Use Log Outputs within the Flow to inspect the mapped
fields for correct data.
• Ensure the Flow ends with the "Create Attachment" action
or sets a target record field to attach the document.
Logic: Document Generation depends on the correct template,
data pill mapping, and action configuration within the Flow.
Common Pitfall:
• Using the wrong or a missing table in the template.
• Forgetting to add the "Create File Attachment" action to
the Flow.
• Not previewing the template with sample data before
testing the Flow.
Question: Your custom Virtual Agent Topic starts
correctly but ends with an error or an unresponsive
screen.
What's causing this?
✔ Answer:
• Use the
Virtual Agent Designer to visually check the dialog
steps for issues.
• Look for errors in the Script logs (
syslog) or the sys_chat_queue table.
• Check if any script in the topic uses incorrect input
variables, session objects, or response handling.
• If the topic uses Scripted REST APIs, validate that those
APIs are active and secure.
Logic: The flow can be broken by scripted actions within the
dialog or by broken integration points.
Common Pitfall:
• Calling an undefined function like
️HackNow Call/WhatsApp: +91 8984988593 Visit Us: [Link]
[Link]().
• Trying to access the
current object without first initializing a GlideRecord
query.
• Receiving poorly formatted JSON responses from Scripted
REST API calls.
Book a One-on-One Call: Facing challenges with ServiceNow administration, scripting, integrations, or real-
world use cases? Book a one-on-one call for expert guidance on streamlining administration, mastering
scripting, seamless integrations, and solving scenario-based challenges. Click here to schedule!
Question: You've configured Predictive Intelligence to
auto-populate the Category field for incoming
Incidents, but it's not working.
Why?
✔ Answer:
• Verify the Machine Learning Solution is trained and its
status is
"Success" in the Solution Definitions.
• Confirm that
Auto Prediction is enabled in the Solution Definition
settings.
• Ensure the input field (like
short_description) is correctly mapped and populated
with data when the Incident is created.
• The Incident form layout must include the predicted field
(Category) for the prediction to be visible.
Logic: Auto-classification is dependent on the quality of the
training data, the solution's status, and the field settings.
Common Pitfall:
• Forgetting to retrain the solution after a data schema
change.
©️HackNow Call/WhatsApp: +91 8984988593 Visit Us: [Link]
• Forgetting to activate the
Auto Prediction setting.
• A mismatch between field types (e.g., the model predicts a
string but the target field is a choice list).
Question: You migrated an Update Set containing a
Business Rule, but it doesn't appear in the target
instance.
What went wrong?
✔ Answer:
• Check if the Business Rule was marked as
"Complete" in the original Update Set before exporting.
• Use the
"Preview Update Set" feature in the target instance to
see exactly which records are included and if there are any
errors.
• The record may have been modified in a different Update
Set, causing it to be excluded from the one you migrated.
• Check the
"Commit Log" in the target instance to verify if the
record was skipped during the commit process.
Logic: Update Sets are selective and scoped; missing
dependencies are a common reason for failure.
Common Pitfall:
• Not capturing dependency records (e.g., a new field the
Business Rule uses) in the same Update Set.
• Editing the same Business Rule in a different, concurrent
Update Set.
• Forgetting to mark changes as "Complete" before
exporting the set.
️HackNow Call/WhatsApp: +91 8984988593 Visit Us: [Link]
Question: Your Scripted REST API works in the global
scope, but returns a "403 Unauthorized" error when
placed in a scoped app.
Why?
✔ Answer:
• Check the
CORS Rules under System Web Services for the scoped
application's namespace.
• Ensure the
"Requires authentication" checkbox on the API
resource is unchecked for public access, or that the calling
client is passing proper authentication headers.
• Verify the user account calling the API has the necessary
roles that are defined under the REST resource's security
settings.
• Confirm that no script logic (e.g., checking
[Link]) is unintentionally blocking anonymous
access.
Logic: Scoped APIs require their own proper permissions and
access policies to function correctly.
Common Pitfall:
• Assuming global security settings automatically apply to
scoped applications.
• Not setting the correct role required to access the API
endpoint.
• Forgetting to enable the API in the
REST API Explorer for testing purposes.
©️HackNow Call/WhatsApp: +91 8984988593 Visit Us: [Link]
Question: You created a Document Template for
Knowledge Articles, but it's not auto-applying when a
user creates a new article.
Why?
✔ Answer:
• Confirm the template is
Published and Active.
• Ensure the template is linked to the correct table, which
should be
kb_knowledge.
• Check if the
Applicability condition (e.g., for a specific category or
language) is too restrictive and not being met.
• The user creating the article must have a role that matches
the roles defined in the template's applicability settings.
Logic: Template applicability is strictly based on its
configuration for a specific table, its conditions, and the user's
roles.
Common Pitfall:
• The template is set for the wrong table.
• The applicability condition does not match the data in the
record being created.
• Forgetting that some workflows require the user to click
"Apply Template" manually.
Need Help? Join Our WhatsApp Community: Struggling with ServiceNow administration, scripting,
integrations, or real-world use cases? Don’t worry! Join our WhatsApp community for real-time support,
tips, and advice from experts and peers on the same journey. You’re not alone—we’re here to help you
succeed. Click here to join the community!
️HackNow Call/WhatsApp: +91 8984988593 Visit Us: [Link]
Question: You set up a Data Source with a custom
Import Script to transform incoming Excel data, but
nothing gets imported and no error appears.
Why?
✔ Answer:
• Verify that the column names in the Excel file exactly
match the keys being used in the script (e.g.,
row["Name"]), as they are case-sensitive.
• Add
[Link]() or [Link]() statements inside the import script's
loop to get visibility and confirm it is running.
• Check that the
.insert() method is actually being called on the
GlideRecord object within the script.
• Make sure the import type on the Data Source is set to
"Script" and not an automatic mapping.
Logic: Import scripts require correct header parsing and
explicit logging to debug; without them, failures can be silent.
Common Pitfall:
• A mismatch in row keys, often due to case-sensitive
headers.
• Forgetting to call the
.insert() method to commit the new record to the
database.
• Having no logging in the script, which leads to the incorrect assumption that the script
.
Book a One-on-One Call: Facing challenges with ServiceNow administration, scripting, integrations, or real-
world use cases? Book a one-on-one call for expert guidance on streamlining administration, mastering
scripting, seamless integrations, and solving scenario-based challenges. Click here to schedule!
©️HackNow Call/WhatsApp: +91 8984988593 Visit Us: [Link]
️HackNow Call/WhatsApp: +91 8984988593 Visit Us: [Link]