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.

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.