Skip to main content

Hey Everyone,

New to Freshservice and working with the workflow automator. I have a situation where when new requesters send their first ticket request, their new user account get a value for the “Department” field, but not the custom “Company” field I added. So, I have a workflow that checks if a ticket is raised, if the “Company” field is blank, update it to match the “Department” field, and then assign it to an agent group.

I can’t query for an individual agent group with the FreshService API but I can query for individual departments, so I added a custom Department field called “assigned_agent_group_id”, and populated it with the correct agent group ID. Then I added a Web Request node to my workflow that queries the department that matches {{ticket.department}} and used a JSON Parser node to get the response body. This is good, the JSON contains the agent group ID I assigned to a department (using the custom field). However, when I add another Web Request node to the workflow to update the ticket, the request is changing the value of the agent group ID that was listed in the JSON parser node, and I don’t know why.

Above is what the request to the department API endpoint looks like for this custom field.

The image below is a variable I added to the JSON parser node to extract just the ID value from the response body, because for some STUPID reason, the parser node always returns individual values inside arrays instead of just the value.

 

The group ID looks correct. The image below is the body sent to the tickets API endpoint, using that custom variable I added to the JSON parser node:

 

The image below is from the execution logs page for this workflow. The group_id value is completely different from the actual agent group ID.

Does anyone know why this is happening? Thanks

- Jack C

Hi.

Quick question:

Are you actually working with Departments?

You maybe interested in setting up MSP mode, where Department is switched to Company, so, you won’t need those other custom field you have created.

You may take a look to this:

How to switch your Freshservice Service Desk to MSP (and back) : Freshservice

 

Best,


Hey ​@eeha0120,

Thanks for the reply. No, we are not actually working with Departments within our org, as we don’t have any. This was a suggestion from the FreshService Product Adoption specialist helping us set up our org, and seems like a simple enough way to manage multiple customers (albeit as “Departments” instead of “Companies”) without having to manage an MSP setup.

Regardless, this doesn’t point to a solution to my problem. Before I tried what was mentioned in my original post (adding a custom agent group ID field to the Departments for easy parsing in web requests), I tried another method without custom fields. I had my workflow automation query the agent groups API endpoint and get the ID from the agent group whose name value matched the ticket department since the API returns an array (I made sure the names matched for ease), and this grabbed the group ID value. However, the web request node that updated the ticket with the group id was still changing the value before submission. After this happened, I tried the method explained in my first post.

- Jack


Got it. Thank you very much for getting back with this additional details.

That’s actually odd.

I might not be seeing something you are, but would it be possible that you are getting the wrong data field in the array?

In your workflow, in the next node following the Parser node, you should be able to get exactly the custom group id field you created without playing with arrays:

 

 

Best,


I know I’m getting the right value, because the value I took a screenshot of (“group_id”:143) is not a value anywhere in the data returned by the parser node.

I used Postman to send my first request to the departments endpoint https://mydomain.freshservice.com/api/v2/departments?query="name:'<department_name>'"

I pasted the response into the JSON Parser node to generate a sample of the expected output I should get when the workflow runs. That is what you see below (w/ redactions). The assigned_agent_group_id is what I’m trying to get (red box). For some reason, this only displays as a single-element array instead of just the number.

This means I can’t just get the ID value in the next node following the JSON Parser node (which is another Web Request node) because the placeholder representing that ID value is passing in an array of n<ID_NUM>] instead of just <ID_NUM>.

So, I was adding another variable to what you see below which is set to Number, and gets the ID in that assigned_agent_group_id array ($.departmentsd0].custom_fields.assigned_agent_group_id). This correctly gets just the number. If I use the test button in the Web Request node, and manually enter a group ID, the request works great. But when the workflow runs automatically, it’s changing an 11-digit group ID integer like 34000164066, to 143.

 


Hey ​@eeha0120,

I can confirm that I am not pulling the wrong data field from the array. This same issue happened when I tried this by using a Web Request node to get the agent groups and accessing the one matching the Department name for a ticket, before ever adding that custom field to the departments with the agent group ID.

I was grabbing the correct field in the next node after the JSON Parser node, and it would always change the value when the workflow ran automatically.

I ended up nixing this whole attempt because even after talking to my product adoption specialist in a meeting yesterday, he wasn’t sure why it was changing it. In any case, I think I was doing something unnecessary, by having Department and Company fields for each requester. I removed the custom Company field and am just sticking with Department, so I don’t have to worry about this odd Web Request node behavior.

I really appreciate you trying to help me sort this out!


I understood. Thank you very much for the explanation and final decision.

Despite of having talked with the PAS and not using it anymore, I’d suggest to submit a support ticket, as this may be a bug which Freshworks should address properly.

 

Best,


Reply