Change task groups

[VenkataSreC]

When change request is created two change tasks created in implementation state when we open those tasks there is an assignment group field is there when I click on assignment group I want only the implementation groups visible I don’t want any other groups will appear how to do that please guide steps

[Mitsua]

Hello @VenkataSreC 

To achieve this, you must first verify how "Implementation Groups" are uniquely distinguished from other groups, as there should be a unique identifying parameter.

If these groups are filtered by a group type, you can add the following to your reference qualifier:

javascript:"typeIN"+gs.getProperty("Implementation");

Rather than using a hardcoded Sys ID of group type I created system property and stored sys_id of group type.

Let mi know if any queries.

Please mark this as correct answer and helpful if it resolved, or mark this helpful if this help you to reach towards solution.

Thanks!

[Mitsua]

@VenkataSreC 

Did my answer help you resolve your issue? If so, please consider marking it as a helpful or accepted solution. This helps others who may have a similar problem

If you're still stuck, let me know, and I'll be happy to help further.

Thank you!

Mitsua

[ChallaR]

hi @VenkataSreC ,

Write an dictionary override with below script -

javascript: current.state == 'implementation' && 'u_group_type' == 'Implementation'

Thanks,

Rithika.ch
  

[MackI]

Hi @VenkataSreC 

### Recommended Solution: Implement a Scripted Reference Qualifier

The most robust way to achieve this conditional filtering is by implementing a **Scripted Reference Qualifier** on the `Assignment group` field of the `Change Task` table (`change_task`).

**Prerequisites:**

1. **Role Required:** You must have the **`admin`** role to perform these configuration steps.
2. **Group Identification:** You must have a way to identify which groups are designated as "Implementation groups." This usually involves a custom field (e.g., `u_type` or `u_implementation_group` set to `true`) on the `sys_user_group` table. For the purpose of these steps, we will assume your implementation groups can be identified by a certain field or characteristic.

**Steps to Implement the Restriction:**

*(Note: The detailed steps for configuring Dictionary entries and Reference Qualifiers are based on general ServiceNow administration knowledge, as the provided sources focus on application configuration rather than platform dictionary definition.)*

#### Step 1: Navigate to the Dictionary Entry for the Change Task Assignment Group

1. Navigate to **All** > **System Definition** > **Dictionary**.
2. Search for the dictionary record for the **Assignment group** field on the **Change Task** table.
* Set the filter condition: `Table` is `Change Task [change_task]` AND `Column name` is `assignment_group`.
3. Open the corresponding dictionary record.

#### Step 2: Implement a Dictionary Override (If Necessary)

If the `assignment_group` field is inherited directly from the Task table (`task`), you will need a **Dictionary Override** to apply a unique filter just for `change_task` records.

1. Look for the **Dictionary Overrides** tab (if the field is inherited).
2. Click **New** (or locate the existing override for the `change_task` table if one exists).
3. Ensure the following fields are set:
* **Table:** `Change Task [change_task]`
* **Override Reference Qualifier:** Checked (`true`).

#### Step 3: Define the Reference Qualifier Script

In the **Reference Qualifier** field (either on the Dictionary entry itself, if it’s defined there, or on the Dictionary Override form):

1. Select the **Advanced** option (if available) or prepend your script with `javascript:` to indicate a scripted reference qualifier.

2. Enter a script that checks the current record's table and state, and returns a filter string (encoded query) for the `sys_user_group` table only if those conditions are met.

**Conceptual Script Example:**

```javascript
javascript: (function() {
var groups = '';

// Check if the record is a change task
if (current.getTableName() == 'change_task') {
// Check if the change task state is 'Implement' (or the correct numerical value for Implementation)
// Note: The Implementation state is often value '3' or equivalent depending on the state model used.
if (current.state == 'Implement') { // Use the internal value/label for the Implementation state
// Define the filter to retrieve only groups categorized as 'Implementation'
// ASSUMPTION: 'type' is a field on sys_user_group used to categorize groups.
groups = 'type=Implementation Group'; // Replace 'type=Implementation Group' with your actual group filtering logic (e.g., u_is_implementation=true)
}
}

return groups;
})();
```

*Self-Correction on State Value:* The sources show that the Implementation state for a change request is usually number 5, but the internal state values for a *change task* (which extends the `task` table) might vary depending on the workflow. You must verify the correct internal value or label for the **Implementation** state on the `change_task` record.

3. **Save/Update** the Dictionary Override or Dictionary Entry.

### Alternative Method: Using Assignment Rules for Auto-Assignment

While this does not restrict the manual lookup list, you can ensure the tasks are automatically assigned to the correct groups upon creation using **Assignment Rules**. This removes the need for users to manually select a group entirely.

You can define assignment rules specifically for change tasks generated for change requests.

**Steps to Create an Assignment Rule (Requires `admin` role):**

1. Navigate to **All** > **System Policy** > **Assignment**, and then click **New**.
2. Define the rule:
* **Name:** E.g., "Auto-Assign Implementation Tasks."
* **Applies To:** Select the table **Change Task [change_task]**.
* **Condition:** Add conditions to match the tasks you want to auto-assign:
* `Type` is `Implementation`
* AND/OR any other necessary fields (e.g., specific Configuration Item or Category).
* **Order:** Set a high order number to ensure this rule runs before other, more general rules.
* **Assign To:** Select the specific **Assignment group** (your Implementation Group) and optionally an **Assigned to** user.
3. Click **Submit**.

This rule will automatically populate the Assignment Group field for change tasks that meet the criteria, reducing the number of times users rely on the manual lookup list.

If the workflow already auto-assigns the tasks (as workflows often generate tasks with the Implementation type and assign them), you might need to modify the underlying **Change Workflow** or **Standard Change Template** definition instead to specify the desired assignment group.

* If tasks are created via **Standard Change Templates**, you can specify **Change Task values** (including the Assignment group) within the template itself.
* If tasks are created via **Workflow/Flow Designer**, you would typically edit the workflow activity step responsible for creating the change task to ensure the Assignment Group field is explicitly set to your desired implementation group. Default workflows sometimes generate tasks in the Implementation state. You may need to explore the relevant flow associated with the change request type (e.g., `Change Request – Normal`).

Disclaimer: Please note that the information and advice provided above are based on my personal experience and are not official solutions or professional advice from DXC Technology. No patent code or solution from DXC Technology has been shared

If this response helped resolve your problem, please kindly mark it as the Best Answer ‌🌠‌. If it gave you some useful insight, a Helpful ‌⛑‌ mark would be wonderful too! Your feedback encourages me to contribute more to our amazing community.