Why Are My ServiceNow Catalog Tasks Not Triggering? A Workflow Debugging Guide

Ever submitted a request in ServiceNow and noticed that no Catalog Tasks were created? This situation can be confusing, especially when the workflow appears to be configured correctly.

In many cases, the issue is not a platform error but a workflow logic or data problem. This guide explains the most common causes and how ServiceNow developers can debug the issue effectively.

The Problem

You submit a Requested Item (RITM) and the request gets approved or auto-approved. However, no Catalog Tasks are generated. In some cases, the request may even move directly to a completed or closed state.

This usually indicates that a workflow activity responsible for creating tasks was skipped or never executed.

Common Misconceptions

• Catalog Tasks always require an assignment group.
• Workflows always execute step-by-step unless there is a visible error.
• If approvals succeed, task creation must occur afterward.

In reality, workflow activities can be skipped due to logic conditions, data issues, or platform behavior.

How Catalog Tasks Are Normally Created

Understanding the normal flow helps identify where the process breaks.

User Request
   ↓
Requested Item (RITM)
   ↓
Workflow / Flow Designer
   ↓
Approval Activities
   ↓
Catalog Task Activity
   ↓
Task created (sc_task)

If any step above is skipped or fails silently, the Catalog Task activity will never run.

Common Causes of Catalog Tasks Not Triggering

1. Skipped Workflow Paths

The most common reason is that the workflow path containing the task activity was skipped.

This may happen when an approval activity returns an unexpected result or when no workflow path exists for a specific outcome.

Examples include:

• An approval activity is skipped due to a script condition.
• The workflow contains no path for rejection or auto-approval scenarios.
• The request transitions directly to a closed state.

2. Platform Patch Issues

Some ServiceNow platform releases have contained workflow-related bugs.

For example, in Yokohama Patch 1, there was an issue where only the first approval activity in certain workflows executed correctly. Subsequent approvals were skipped, which prevented downstream tasks from being created.

This issue was resolved in later patches, but older workflows cloned from that version may still behave incorrectly.

3. Data Validation or Missing User Information

Many workflows use user attributes to determine approval logic. If required data is missing, workflow decisions may evaluate to false.

Examples include:

• The requester has no manager defined.
• User profile attributes such as department or location are missing.
• Custom script conditions return null or empty values.

If an approval step is skipped because of these conditions, the workflow may bypass the task creation activity entirely.

How to Debug the Issue

When Catalog Tasks are not created, start with these checks:

• Open the Requested Item (RITM) record.
• Check the Workflow Context related to the request.
• Review each activity and verify whether it executed or was skipped.
• Inspect approval activity results.
• Validate requester and user data fields.

Step-by-Step Debugging Checklist

• Verify that the workflow or Flow Designer flow is attached to the catalog item.
• Check the workflow context for skipped activities.
• Confirm approval results and approval states.
• Validate requester data such as manager, department, and location.
• Review any script conditions in approval or decision activities.
• Check for platform patch-related issues.
• Confirm that the Catalog Task activity exists in the executed workflow path.

Useful Logs for Troubleshooting

If custom scripts are involved, adding logging can help track execution flow.

gs.info('Approver: ' + current.requested_for.manager);
gs.info('Workflow state: ' + workflow.state);
gs.info('Task creation reached: ' + activity.name);

These logs can help identify where the workflow path stopped executing.

Best Practices for Preventing This Issue

• Define workflow paths for every approval outcome.
• Ensure requester data fields are properly populated.
• Add logging for critical workflow decision points.
• Test workflows with incomplete user data to simulate edge cases.
• Review workflows after platform upgrades.

Common Search Queries This Article Solves

This guide helps ServiceNow developers searching for solutions to problems such as:

• ServiceNow catalog task not created
• ServiceNow catalog task not triggering workflow
• ServiceNow RITM approved but no catalog tasks
• ServiceNow workflow skipped activity
• ServiceNow debugging catalog task creation
• ServiceNow workflow approval skipped

Conclusion

Catalog Tasks not triggering is usually caused by workflow logic, skipped activities, or missing user data rather than a platform failure.

By reviewing the workflow context, validating approval logic, and checking user data, ServiceNow developers can quickly identify the root cause.

Understanding how workflow paths execute is essential for troubleshooting task creation issues effectively.

Read More

ServiceNow: Remove Role from Large User Group Without Timeout (20k+ Users)

ServiceNow: Remove a Role from a Large User Group Without Timeout Issues

Managing roles in large ServiceNow environments can sometimes lead to performance challenges. One common issue occurs when attempting to remove a role from a group containing thousands of users.

Recently, I encountered a situation where a group had more than 20,000 users and an incorrect role had been assigned. Attempting to remove the role through the ServiceNow UI repeatedly resulted in timeout errors.

This article explains the issue and the approach used to safely remove the role without causing performance problems.

The Problem

A role was mistakenly assigned to a large ServiceNow group containing more than 20,000 users. The role also contained several child roles, which expanded the number of inherited permissions across the platform.

Attempts to remove the role through the ServiceNow UI or via a synchronous Fix Script consistently resulted in timeout errors.

The main challenge was that removing the role triggered role recalculations for thousands of users at once.

Why Timeout Happens

When a role is removed from a group, ServiceNow must re-evaluate role inheritance for every user in that group.

The typical inheritance flow looks like this:

User
   ↓
User Group
   ↓
Group Role (sys_group_has_role)
   ↓
Inherited Roles
   ↓
User Role Updates

When a group has tens of thousands of users, this recalculation can exceed request execution limits and cause timeouts.

The Solution: Enable Asynchronous Role Updates

ServiceNow provides a system property that allows group role updates to run asynchronously instead of within the user session.

Enable the following system property:

glide.ui.schedule_slushbucket_save_for_group_roles = true

When this property is enabled, role changes are processed through background jobs rather than the UI request thread.

This prevents timeout errors when modifying roles on very large groups.

Optional Fix Script for Role Removal

If automation is required, the role can be removed by deleting the relationship record in the sys_group_has_role table.

var groupName = 'Your_Group_Name';
var roleName = 'role_a';

var group = new GlideRecord('sys_user_group');
group.addQuery('name', groupName);
group.query();

if (group.next()) {

    var role = new GlideRecord('sys_user_role');
    role.addQuery('name', roleName);
    role.query();

    if (role.next()) {

        var groupRole = new GlideRecord('sys_group_has_role');
        groupRole.addQuery('group', group.sys_id);
        groupRole.addQuery('role', role.sys_id);
        groupRole.query();

        while (groupRole.next()) {
            groupRole.deleteRecord();
            gs.info('Removed role ' + roleName + ' from group ' + groupName);
        }

    } else {
        gs.info('Role not found: ' + roleName);
    }

} else {
    gs.info('Group not found: ' + groupName);
}

This script removes the group-role relationship directly from the platform.

What Happens After Removing the Role

Once the group-role relationship is removed, ServiceNow automatically recalculates role inheritance for users in the background.

If a user no longer inherits that role through another group or direct assignment, the role will be removed from their user record.

This recalculation is handled asynchronously when the system property mentioned earlier is enabled.

Best Practices for Large Role Changes

• Enable asynchronous processing for group role updates.
• Test role changes in a lower environment before applying them in production.
• Monitor background jobs when performing role changes affecting large groups.
• Avoid making large role changes during peak platform usage.

Common Search Queries This Article Solves

This guide helps ServiceNow administrators and developers who encounter issues such as:

• ServiceNow remove role from large group timeout
• ServiceNow group role removal performance issue
• ServiceNow role inheritance recalculation slow
• ServiceNow sys_group_has_role deletion script
• ServiceNow removing roles from large groups

Conclusion

Removing roles from large groups in ServiceNow can cause performance issues if the platform attempts to process all role recalculations within the same request.

By enabling asynchronous role updates and carefully removing group-role relationships, administrators can safely perform role changes even in environments with tens of thousands of users.

Understanding how role inheritance works in ServiceNow helps prevent unexpected performance problems during access management changes.

Read More

Enabling Multiple Form Columns ServiceNow Quiz

Form layout options help improve usability and readability. This question focuses on who is allowed to enable multiple form splits, which is a platform-level setting rather than a simple form personalization option.

---

❓ Quiz Question

Form splits help you organise fields on a form into columns for improved visual layout.
What role is required to enable multiple form splits on the platform?

---

✅ Correct Answer

✔ admin

---

❌ Incorrect Options

• personalize_form

• itil

• form_admin

---

🔍 Detailed Explanation

Form splits allow a form to be divided into multiple vertical columns, making large forms easier to read and use. However, enabling multiple form splits is controlled at the system level, not at the individual form level.

Because of this, the capability is restricted to users with elevated permissions.

---

✔️ Why admin Is Required

• Multiple form splits are enabled using a system setting

• System-wide properties can only be modified by administrators

• Once enabled, form designers can arrange fields into multiple columns

📌 Key point: Only users with the admin role can enable this feature across the platform.

---

⚙️ How Multiple Form Splits Are Enabled (Conceptual)

Administrators must:

1. Enable the system setting that allows multiple splits

2. Make the option available in the form layout interface

After this, forms can be configured with more than one column.

---

❌ Why the Other Options Are Incorrect

🚫 personalize_form

• Allows basic form layout changes

• Does not grant permission to modify system-wide settings

---

🚫 itil

• Used for working with task and service records

• Has no authority over form configuration settings

---

🚫 form_admin

• Manages form layouts and UI elements

• Cannot enable platform-level features

---

📱 Additional Behavior to Know (Exam Tip)

When a form with multiple splits is viewed on a small screen:

• Fields in the first column appear before fields in later columns

• This ensures usability on mobile devices

---

🧠 Overall Explanation Summary

• Form splits improve visual layout by creating columns

• Enabling multiple splits is a platform-wide action

• Only admin users can enable this capability

• Other roles are limited to form customization, not system settings

---

🏁 Final Thoughts

For exam questions, remember:

If a feature requires changing system-level behavior, the answer is almost always “admin.”

This rule applies strongly to advanced form configuration.

Read More

ServiceNow Quiz on ACL Decision Types

Access Control Lists (ACLs) are fundamental to securing data. This question focuses on identifying the two decision types used in ACL rules and understanding how they control access.

---

❓ Quiz Question

Access Control List (ACL) rules allow you to specify the decision type, rule type, and operation that defines them.
What are the two decision types in ACL rules?

👉 Select 2 answers from the options below.

---

✅ Correct Answers

✔ Allow If
✔ Deny Unless

---

❌ Incorrect Options

• Deny Always

• Allow Once

• Restrict Access

---

🔍 Detailed Explanation

ACL rules define how and when access is granted or denied to secured objects. The decision type determines how the system interprets conditions in the rule.

There are exactly two decision types.

---

✔️ The Two ACL Decision Types

🟢 Allow If

• Grants access only if all conditions are met

• Commonly used to explicitly permit access

• Evaluated after deny rules

📌 Think of it as: “Allow access if this rule matches.”

---

🔴 Deny Unless

• Denies access unless all conditions are met

• Evaluated before Allow If rules

• Takes priority during ACL evaluation

📌 Think of it as: “Deny access unless this rule matches.”

---

⚠️ Important Evaluation Rule

Deny-Unless ACLs are evaluated before Allow-If ACLs.

This ensures that restrictive rules override permissive ones when conflicts exist.

---

❌ Why the Other Options Are Incorrect

🚫 Deny Always

• Not a valid ACL decision type

---

🚫 Allow Once

• Not a recognized access control behavior

---

🚫 Restrict Access

• A generic phrase, not an ACL decision type

---

🧠 Overall Explanation Summary

• ACLs use decision types to control access logic

• Only two decision types exist:

  • Allow If

  • Deny Unless

• Deny-Unless rules take priority

• Other options are distractors

---

🏁 Final Thoughts

For exams, remember:

If the question asks for ACL decision types, the answer is always “Allow If” and “Deny Unless.”

Nothing else qualifies.

Read More

ServiceNow Quiz on Creating List Filters with Multiple Conditions

Filtering lists is a daily activity for users and administrators. This question tests your understanding of how to correctly apply multiple filter conditions so that only records meeting all requirements are displayed.

---

❓ Quiz Question

You have a requirement to create a set of filter conditions on the Incidents list to show:

• Incidents where the state is Resolved or Closed

• Incidents where the Assignment Group is one of your groups

After clicking the Funnel icon and defining the first condition, what steps should you take?

---

✅ Correct Answer

✔ Click AND button; define the second condition; click Run.

---

❌ Incorrect Options

• Click AND button; define the second condition; press the Save button

• Select Assignment group on the Search box on the top bar; press enter

• This requirement cannot be achieved by the list filters since it requires advanced reporting

• Click Run; overwrite the first condition with the second condition; press enter

• Click OR button; define the second condition; press Run

---

🔍 Detailed Explanation

A filter controls which records appear in a list by applying one or more conditions. For a record to appear, it must meet the criteria defined in the filter.

In this scenario, both conditions must be true, so they must be joined using AND.

---

🧩 How List Filter Conditions Work

Each filter condition includes:

1. Field – the column being evaluated

2. Operator – how the value is compared

3. Value – the data being matched

4. Grouping – how conditions are combined (AND / OR)

---

✔️ Why the Correct Answer Is Right

🟢 Using AND to Combine Conditions

• AND ensures that both conditions must be met

• The filter evaluates all AND-linked conditions together

Correct sequence:

1. Define the first condition

2. Click the AND button

3. Define the second condition

4. Click Run

This immediately applies the filter to the list.

---

❌ Why the Other Options Are Incorrect

🚫 Saving Instead of Running

• Save stores the filter but does not apply it immediately

• The question asks how to show the records

---

🚫 Using the Search Box

• The search box performs a text-based search

• It does not apply structured filter conditions

---

🚫 Using OR Instead of AND

• OR would return records meeting either condition

• This would include unwanted records

---

🚫 Overwriting Conditions

• Replacing conditions removes earlier criteria

• Both conditions must exist at the same time

---

🚫 Advanced Reporting Claim

• List filters fully support this requirement

• No reporting or advanced tools are needed

---

🧠 Overall Explanation Summary

• Use AND when all conditions must be met

• Define conditions first, then click Run

• OR is used only when either condition is acceptable

• List filters are sufficient for this scenario

---

🏁 Final Thoughts

For exams, remember:

If the requirement says “and”, use the AND connector and click Run.

This simple rule eliminates most distractors.

Read More