Hi @Dan D 

You should create a new topic in the community within the correct forum. Currently you use Freshservice subforum asking for help within Freshdesk.

Hi @Dan D,

Assuming you're referring to Service (not Desk):

I’d recommend avoiding a second group here, as it may be unnecessary.

Instead, here’s a streamlined approach:

1. Set up a workflow to tag "special requests" that require a secondary audit.
2. Create a new status called "Audit" (or another relevant term). You can use Business Rules to make this status visible only for special requests.
3. Configure a workflow that triggers when a special request moves to "Resolved." At this point, it should set the status to "Audit" and assign the request to a team member for an approval task. Add a condition ensuring that the approver is not the same as the initially assigned agent.
4. Optionally, add a task with a round-robin assignment to distribute work evenly. Freshservice can also check that the task assignee is different from the original agent.

This should keep things efficient while adding the necessary audit oversight.

Hi @Roxwell,

I totally agree with your approach. How do you make the approval in your third point seem more ‘random’ as a hard coded value for approver might not work. Any idea? 

(Just brainstorming here!) I’d suggest using a Password Generator app combined with a custom object to generate a random record number, which could then be sent to the appropriate person. This would ideally benefit from loops, to handle the chance of the same agent being selected…but unfortunately, we don’t have those just yet.

Alternatively, you could set up a webhook to fetch the group members. Then, use the random number generator to pick an index from the array and apply an expression/parser combo to isolate the chosen agent. This method would be more sustainable, as it dynamically adapts to changes in group membership without manual updates.

 I had a play with my idea….. It’s not pretty… I’ll post up about it later.  @DanielRuff 

@Dan D  - Having two queue may be your best solution, and then when the ticket is marked as audit, move it to the new queue, enable round robin on that queue, add an approval task for the assigned agent. The challange is the checking that the Agent is different, but you may be best off making it a.clear policy not to “approve” your own and spot checking. As checking, really needs loops and Fresh can’t do that yet. 

@Roxwell, I appreciate your insights.

I propose we consider a hybrid approach utilizing both state and hidden fields. For instance, we could employ two hidden fields to store the ID of the agent who initially handled the ticket. While using the API is a possibility, it might introduce unnecessary complexity.

Here’s a potential workflow:

Status: “In Progress” - Agent A is actively working on the ticket.

Status: “Audit” - Agent A changes the status to “Audit”, which unassigns the agent and moves the ticket to a different queue managed by a round-robin algorithm.

Case 1: Agent A is reassigned by round-robin

It’s unclear if the round-robin assignment can trigger a workflow. If it can, we should compare the assigned agent with the previously stored agent ID. If not, we can perform this check when the agent attempts to transition the ticket from “Audit” to “Resolved”. If the same agent is detected, we can prevent the transition and notify the agent accordingly. Additionally, a note indicating the previous agent’s involvement would be beneficial. I don’t see a clean solution to prevent an agent being selected twice by round robin.

Case 2: Agent B is assigned by round-robin

In this scenario, the process proceeds smoothly, allowing Agent B to review and resolve the ticket.