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

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 can be confusing — especially when everything looks fine in the workflow. Let's break down the common causes, real-world pitfalls, and how to effectively debug them.

🔍 The Issue

You submit a Requested Item (RITM), and it gets approved or auto-approved, but no tasks appear. The item is closed or marked as complete without any actionable tasks.

🤔 Possible Misconceptions

• Catalog Task requires an Assignment Group to be present (Not always true)
• Workflow always proceeds step-by-step unless there’s an error (Also not true)

💡 Key Truths and Real Causes

1. 🚫 Skipped Workflow Paths

Sometimes tasks are not triggered simply because the workflow path was skipped. This typically happens when an approval activity results in a state that bypasses subsequent activities.

Examples:

• An approval step results in skipped due to business logic or error
• No defined flow path for a non-standard approval outcome
• Request gets auto-closed by moving directly to a closure state

2. ⚠️ Platform Bugs (e.g., Yokohama Patch 1)

In ServiceNow Yokohama Patch 1, there was a known issue where only the first approval in a multi-approval workflow was triggered. All subsequent approvals were silently skipped — which also meant downstream tasks never got executed.

This issue was resolved in later patches (Patch 2+), but workflows using older logic or clones from that release may still carry the flaw.

3. 🔄 Skipped Due to Data Validation Logic

Many organizations use logic like gs.getUser().getManager() or user profile attributes in approval decisions. This can lead to approvals being skipped when:

• The requester has no manager defined
• The user’s department, group, or location info is incomplete or invalid
• Custom script conditions evaluate to false or empty, skipping approval

When the approval step is skipped, the workflow may proceed directly to closure, leaving task creation activities behind.

🧰 How to Debug This

1. Check the Workflow Context of the RITM
2. See if the Approval Activity ran or was skipped
3. Verify the data on the Requested Item and Requester
4. Test your approval logic (especially if you use custom conditions)
5. If on Yokohama Patch 1, consider upgrading or reviewing workflow logic

🛠️ Useful Logs to Monitor

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

📌 Best Practices

• Always define clear flow paths for all approval outcomes
• Use default values or validations for requester/manager fields
• In high-impact workflows, include logging and alerts for skipped activities
• Test workflows with incomplete user data to simulate edge cases

✅ Conclusion

Catalog Tasks not triggering is often not a bug, but a logic issue. By understanding how approvals, data integrity, and workflow paths interact — especially across platform patches — you can resolve such issues quickly and confidently.

Always validate your data-driven decisions and watch for skipped workflow activities.

Have you faced similar task creation issues in ServiceNow? Let’s discuss in the comments!

Read More

How to Remove a Role from a Large User Group in ServiceNow Without Timeout Issues

How to Remove a Role from a Large User Group in ServiceNow Without Timeout Issues

Recently, I encountered a tricky situation in ServiceNow while trying to remove a specific role from a large user group. The group had over 20,000 members, and the role I wanted to remove — let’s call it role_a — had multiple child roles.

Whether I tried removing the role from the group through the ServiceNow UI or via a Fix Script, the operation consistently timed out or failed due to performance issues. Here’s how I managed to solve it using a lesser-known system property and a careful approach.

🔍 The Problem

• Group had 20,000+ users
• role_a was mistakenly added to the group
• Child roles expanded the impact even more
• Removal via UI or script timed out

This scenario made direct deletion via UI or synchronous script execution impractical and risky for performance.

💡 The Solution: Enable Asynchronous Role Removal

ServiceNow provides a system property that allows large-scale group role changes to be scheduled and processed asynchronously — which prevents timeout issues.

✅ Set this property to true:

glide.ui.schedule_slushbucket_save_for_group_roles = true

This tells ServiceNow to schedule the removal process as a background job instead of executing it immediately in the user session, allowing even large role removals to be processed safely.

🧰 Correct Fix Script (Optional, for Automation)

While the UI works fine with the above property enabled, here's a safe fix script that removes a role from a group by deleting the record from 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);
}

⚠️ Note: You do not need to manually remove the role from each user — ServiceNow will automatically update user-role associations in the background after removing the group-role link.

🔄 What Happens Next?

Once the group-role relationship is deleted, ServiceNow automatically re-evaluates each user’s role inheritance. If a user no longer inherits that role from any group or assignment, it is removed.

The async job processes this in the background — all thanks to the property:

glide.ui.schedule_slushbucket_save_for_group_roles = true

📌 Final Thoughts

This small configuration change made a huge difference — what was previously a timeout-prone operation became a background task that completed smoothly.

Always remember to handle role management in large environments carefully. System properties like this one can make the difference between a performance issue and a seamless experience.

Have you faced similar issues with group or role management? Share your experience in the comments below!

Read More