feat: Dynamic ticket assignment #115

[vhudlikar]

feat: Dynamic ticket assignment #115

Dynamic Ticket Assignment Action:

This Action introduces a core automation feature to ensure tickets are assigned fairly based on live workload, picking the person in the team who is the least busy.

---

Action Inputs

Component	Purpose
Table Name	The table to query (e.g., incident).
Group	The team whose members need evaluation (e.g., Test Group).
Group Field	The technical name of the field that holds the team's ID (e.g., assignment_group).
Assigned User Field	The technical name of the field that will receive the user's ID (e.g., assigned_to).
Excluded Members	A list of users the tool must ignore during assignment.

---

Action Outputs

Component	Purpose
Assigned User Sys ID	The unique ID of the individual selected.
Assignment Count	The minimum count of active tickets they currently have.
Success Status	YES or NO (Did the tool find someone?).
Error Message	A simple message explaining why assignment failed.

---

Logic

This action ensures fair workload distribution by reliably finding the most available person within a target group.

1. Validate Inputs (Pre-Check): The action first verifies all critical inputs: the Table Name, Group Field, and Assigned User Field must exist on the specified table. It also retrieves the Sys IDs for the Target Group and Excluded Members using the robust getValue('sys_id') method to prevent data type errors.
2. Filter Excluded Members: The script reads the list of Excluded Members using the safe _next() iterator pattern. This ensures that even if only one member is excluded, their Sys ID is correctly extracted and placed into a list, regardless of the Flow Designer input type structure.
3. Identify Eligible Team Members (Two-Step Search): To reliably find available users, the script performs a robust two-step query, bypassing dot-walk issues that can occur in Flow Designer scripts:
   • Queries the sys_user_grmember table to get the Sys IDs of all users in the Target Group.
   • Queries the sys_user table using that list to filter for only those users who are currently marked as Active and NOT in the Excluded Members list.
4. Determine Least Busy User: The script executes a GlideAggregate query for each Eligible Member to count their currently active tickets in the group. It tracks the lowest count found (minCount) and assigns the ticket to that user.
5. Deliver Results & Status: The action sets the Assigned User Sys ID and the final Assignment Count (explicitly cast to an integer to avoid 0.0 outputs).

---

Data Setup

All tests were performed using the following simplified data structure:

Data Component	Details	Notes
Group Name	Test Group	The single team evaluated.
Group Members	User A, User B, User C	Three active users used for all test scenarios.
Incident Data	INC 1, INC 2, INC 3	Three active incidents used to simulate various workloads.

---

Test Use Cases (Positive & Negative)

Test Case Goal	Workload Setup (Active Incidents)	Excluded Members Input	Expected Result (Assigned To)	Pass Condition
T1: Least Busy (Positive)	User A: 0, User B: 1, User C: 2 (Simulated)	None	User A (Count 0)	Action successfully picks the user with the lowest active workload.
T2: Tie-Breaker (Positive)	User A: 1, User B: 1, User C: 1 (Simulated)	None	User A or User B (Count 1)	Action correctly assigns when multiple users share the lowest workload.
T3: Basic Exclusion (Negative)	A: 1, B: 2, C: 0 (Simulated)	User C (The least busy user)	User A (Count 1)	The excluded person (C) is correctly ignored, and the next least busy (A) is assigned.
T4: No Eligible Members (Negative)	A: 1, B: 2, C: 3 (Simulated)	User A, User B, User C (All active members)	FAILURE (Error Message)	Action fails gracefully, showing Success Status: false and the error "No eligible active members found...".

[github-actions]

✅ Valid PR for ActionPack

Thank you for your contribution. This PR complies with the CONTRIBUTING.md.
A maintainer will review this shortly. In the meantime, Happy Hacking!