Read only ticket field for agents | The place for Zendesk users to come together and share
Skip to main content
November 5, 2019
Parked

Read only ticket field for agents

Related products:Support
  • November 5, 2019
  • 34 replies
  • 151 views

Maybe consider to create "Read Only ticket fields for agents".

 

    34 replies

    Travis11
    November 5, 2019

    There's an app from Zendesk called Ticket Field Manager (https://www.zendesk.com/apps/support/ticket-field-manager/?q=mkp_ticket%20field%20manager) that does just this.

    If it worked.

    When I made the fields read-only, most of my fields disappeared. When I tried again, the fields were not read-only. (And an error appears in the browser's console.)

    I have a ticket open with Support and they're investigating. Hopefully, they'll be able to fix it and it's the solution for your needs.

    Dan Cooper
    Contributor
    November 5, 2019

    I think the frustrating thing here is that you have to use an app in order to get this functionality today.  However, I'd expand the use case a bit to set expectations for how data is populated into these read-only fields. I would assume that a read only field for agents would need a method to collect an initial value which could come from one of the following scenarios/examples: 

    1) By end users - preserving end user field submissions

    2) By allowed agent groups and/or roles - supporting workflows like approvals, quality assurance, reporting, etc. 

    3) By an application - this is technically supported as the Zendesk App Framework can push data into a field and set a field as read only.  However, an unauthorized user might be allowed to update a field via an authorized app. 

    November 20, 2019

    I agree it is necessary for us to have a read only field.

    Some fields are populated from a 3rd party system through integration and I do not want agents to make changes to those fields

    Dave15
    December 30, 2019

    This has been a feature request placed many many times. WIth the new Zendesk <-> SFDC sync comming shortly this is critical to have the ability to mark a subset of Org and Contact feilds as Read Only.  The lack of this functionality will lead to data hygiene issues in the two systems. 

     

    EG 1:  The Agent changes the Org Name in Zendesk to the customer DBA Name, this then triggers the legal name in the SFDC Account record to be changed to the DBA, which for accounting purposes is not valid. 

    EG 2:  The Agent changes the name of a End-User to Bob Dobbs, as that is Robert Dobbs' perfred name.  Now SFDC has  Bob Dobbs and any contracts that are automatically generated and sent to Mr. Dobbs are not valid in as they do not have the signatories legal name. 

     

    EG 3: An org record has a custom feild for "Assigned Account Manager" that syncs with SFDC Account Owner field.  The Agent changes the value in zendesk for some reason, then the Account record in SFDC is updated and the account manager has "lost" the account and it no longer shows on her revenue reports or tasks of customers to send renewal notices too.  

     

    PLEASE HONOR THIS FEATURE REQUEST.  this is not a training agents issue, this is a data hygiene and consistency issue.  This will only get worse for larger customers that intergrate Zendesk via IPAAS or middleware. 

     

    March 20, 2020

    Hi - We're also needing this.  There are too many "oops" situations where agents accidentally delete or manipulate fields that we need to stay static for integrations and other automations we've built to work.

    Any ETA on this?

    Thanks!

    Alexey14
    April 21, 2020

    This feature is vital, so could you please provide any ETA?

    May 1, 2020

    +1. We want to link zendesk users with their stripe accounts via the stripe customer id. We don't want this field to be editable by agents because they can accidentally change it. 

    June 17, 2020

    +1 for this as well

    June 26, 2020

    Zendesk should provide this feature of making a field Read-only. It is very important in many aspects.

    Nick54
    July 2, 2020

    +1 for this - specifically for fields populated by an integration.