Has there been a change to serverless payload information for Custom fields?

Up until today, I had a working custom serverless application that would work onTicketCreate. Its job was to take the value of a custom field from the department page and post that value as a private note in a freshservice ticket. All using the freshservice Request API. This was working flawlessly, but now the value that is posted in the private note from that custom field in freshservice’s department page is appearing as “undefined” even though no changes have been made to the app’s code, or the value in the custom field.

One thing I have noticed and am not sure was always the case, is that custom fields in a serverless payload appear to be an array of custom fields.

So what was working:

let data = JSON.parse(data.response);
let favSuperHero = data.department.custom_field.cf_super_hero
console.log(`My favorite superhero is ${favSuperHero}`);

My favorite superhero is Batman

Now returns:
My favorite superhero is “undefined”

Any help would be greatly appreciated. Thank you



Hi Zach,

Quite the strange issue. Would it be possible for you to log and share the custom_fields(for the schema information, you can omit out protected data), especially for the case where it comes as an array? And also is this array type field something which you are getting occasionally or persistently?


Hello @prithvi

Here is the payload from a test ticket that I created. You should be able to see that the custom fields from the “args” payload show an array, then when I log the “data” response from the request api, it shows custom fields as an array of objects. then when I try to narrow down to one specific custom field and log the value of that field it says undefined, where before it would return the value.

Here is the server.js code from the application (hope I didn’t reveal too much sensitive information lol )
exports = { events: [ { event: 'onTicketCreate', callback: 'onTicketCreateHandler' } ],

    // args is a JSON block containing the payload information.
	// args['iparam'] will contain the installation parameter values.
	onTicketCreateHandler: function(args) {
		console.log('App Activated');
		console.log(args) // remove for production
		let ticketID = args.data.ticket.id;
		let ticketCategory = args.data.ticket.category;
		let pcNumber = args.data.ticket.department_id;
		if (ticketCategory === 'CEDNet') {
			const getOptions = {
				headers: {
					Authorization: 'Basic <%= encode(iparam.api_key) %>'
					'https://<%= iparam.freshservice_subdomain %>.freshservice.com/api/v2/departments/' + pcNumber,
				.then(function(data) {
					let deptData = JSON.parse(data.response);
					console.log(deptData); // remove for production
					/* When working in the sandbox the below field is .custom_fields.cednet_version
					   When working in productuin the below field is .custom_field.cf_cednet_version
					let cednetVersion = deptData.department.custom_fields.cednet_version;
					console.log(cednetVersion); // remove for production
					const postOptions = {
						headers: {
							Authorization: 'Basic <%= encode(iparam.api_key) %>',
							'Content-Type': 'application/json'
						body: JSON.stringify({
							body: `Ticket identified as CEDNet related issue. Current version at time ticket was created is "CEDNet v.${cednetVersion}"`
							'https://<%= iparam.freshservice_subdomain %>.freshservice.com/api/v2/tickets/' +
								ticketID +
							function(data) {
							function(error) {
				function (error) {

Hope this helps. Thank you for taking a look.

This is a representation of how data was presented prior to this issue. Which shows that custom fields were a single object of key:value pairs


Now they are an array of individual custom field objects

1 Like

I found a workaround
let cednetVersion = deptData.department.custom_fields[7].value;

Identifying the custom field’s index in the array allowed me to extract the value of that field. But this seems cumbersome and could pose issues in the future if the fields are moved into different locations on the department page. And there is no guarantee that their index is the same from sandbox to production.


1 Like

we have had a main problem in freshservice for about 2 weeks.

custom_fields are set to <null> after a ticket status is changed.

Support can confirm the problem.
Unfortunately, we have still not been offered an answer / solution.

it was passed on internally to the freshservice developers 1 week ago.
So there have definitely been changes to the database / API. contrary to the statements of the support …


(edit: custom_field value was hidden… <null>)


I realise this is kind of uncertainty even myself as a developer wouldn’t prefer, @HoJ & @Zach.

We are actively working with :freshservice: team identify the core issue. I am able to confirm that there are no recent breaking changes made specific to payload structure and the way app platform handles the events.

We are looking further into how custom fields attribute gets it’s value populated to find more clues to fix it. Thank you for sharing the information which you thought was helpful. That certainly helped us make some progress.


Had a call with some technical folks today - the Custom Fields definition did change, from a key-value pair (strings), to an array of Custom Field objects.

We were told that the change was not planned or intended, and that it would be reverted in the next day or so.

As we didn’t know what was going on, we adjusted our integration code to handle the change (via trial-and-error, we figured out what had changed and how to address it). We’ll have to rollback those changes as soon as the integration “breaks” again.

Fingers crossed.


Thank you @JosephDMarsh. I was also just made aware of this. I am glad that it was identified. Thought I was going crazy lol. I lucked out in the sense that I kept my old source code so reverting back for my custom application shouldn’t be to difficult. Hope it goes smooth for you as well.


1 Like

For the followers of this thread, and @Zach, @JosephDMarsh & @HoJ

We worked closely with :freshservice: team yesterday to dig deeper to find out what really happened.

  • Team were focussing on a enhancement to the codebase and as a side-effect it broke /v2/departments APIs payload specific to Custom Fields.
  • Team has taken this up with highest priority and bug will be deployed today morning IST and fix will be live around 4:00 PM IST. But hey, give it couple of hours if you don’t see fix at 4:01 PM IST.

Thank you for taking up responsibility of your users of the app. We could have done better. Appreciate all of your proactiveness in reporting issues, it will only help us collectively offer expected outcomes to the user.


hi there

for us, the problem still persists …

best regards

I have taken this up with :freshservice: team. They confirmed the fix went live on the time and date as promised. Can you please check again? If the problem persists, please create a newer topic (feel free to reference this thread if needed) assuming the issue you’re seeing might be different to one on this thread.

Hey everyone, I will say that after the fix went out, the custom fields were back to being key:value pairs but the naming scheme was different. So in my application, the value was coming back undefined. What was originally identified as cf_my_custom_field was now represented as my_custom_field. A little change in my source code fixed the issue and I no longer had to dig through an array of custom field objects.

Hope that helps those still having issues.

our issue depends on the following behavior.

“custom_field”: {
“bereich_86915”: “Voice”,
“rapport_abgegeben_86915”: “false”,
“verrechnet_86915”: “false”

“custom_field”: {
“bereich_86915”: “Voice”,
“rapport_abgegeben_86915”: false,
“verrechnet_86915”: false,
“material_86915”: null

until here everything is fine…

after closing ticket through API…
the custom_fields are resettet…

"custom_field": {
    "bereich_86915": "Voice",
    "rapport_abgegeben_86915": null,
    "verrechnet_86915": null,
    "material_86915": null

so a false value getting nulled after ticket close…

our ticket was opened 3 weeks ago… without a olution…

edit: lol, can’t set more then 1 code-block in the same answer…