Read-only custom org/user fields

30 Comentários

  • Craig Hamm
    Ações de comentário Permalink

    We have need of this, too. One of our fields is our internal extension, but our agents are putting customer extensions in the field. It is used by our phone system to direct tickets to agents that answer calls. I'm trying like heck to figure out how to hide it!

    1
  • Kelli Swygert
    Ações de comentário Permalink

    Any new information about read-only custom user fields? We're encountering the same issue.

    2
  • Everett Griffiths
    Ações de comentário Permalink

    +1.  Far too easy to accidentally delete data.

    2
  • Ludovic Garcia
    Ações de comentário Permalink

    I join them on this need.

    Support user's are not all aware of the impact of manually changing a field that they should never change.

     

    Read-only fields are vital

    1
  • Heather Rommel
    Ações de comentário Permalink

    yes!!!

    +1!!!

    Also, please add any changes to users and/or organizations to the audit log!

    3
  • Lionel Laffineur
    Ações de comentário Permalink

    Any update here ?

    Is it possible to make custom fields read-only now ?

    2
  • Sheldon Dickinson
    Ações de comentário Permalink

    Zendesk, do you plan on chiming in on this one? 

    0
  • Chris Hall
    Ações de comentário Permalink

    +1 please :)

    0
  • Mindaugas Verkys
    Ações de comentário Permalink

    +400

    0
  • Dan Ross
    Ações de comentário Permalink

    While I truly believe access controls should be specific to fields (with read/edit access rights being assigned per field) we found a way to accomplish this. 

    We have agent roles set as unable to create or edit organizations. We then have our CRM integrations user set with permissions to create/update orgs. Thus, we can write the customer ID to the Organization, and it can be searchable using the custom field name, followed by a colon, then the value.

    ex: customer_id:12345

    This way, agents can search for customers by their ID but cannot edit or remove the data.

    Hopefully that helps!

    1
  • Nicole - Community Manager
    Ações de comentário Permalink

    Thanks for sharing, Dan. 

    0
  • Dave Kaminsky
    Ações de comentário Permalink

    So to be clear here, is this feature request getting actioned? 

    a 5 year old request with no "we are" or "we are not" doing this.  Clearly, there is a need to have some Org fields to be editable by A & B agents, but others are R/O for B.  

     

     

    2
  • Nicole - Community Manager
    Ações de comentário Permalink

    Hi Dave, 

    Nothing is being built related to it at the moment, however we are also not saying no to it. It just hasn't ever been business-critical for a significant enough number of users for it to rise to the top of the priority list to date. 

    0
  • Dan Ross
    Ações de comentário Permalink

    As an update to this request,  I recant my previous optimism!

    The solution I posted previously works for that use case but we've had several scenarios where we've wished to log data on a customer profile, but want to be sure that it cannot be removed or modified by agents.

    However, we still need agents to be able to edit *some* of the fields on a user profile, such as phone numbers, or update emails. Right now it's all or nothing.

     

    Please consider creating options around each field configuration to allow for role-based read-only & read/write restrictions!

     

     

    3
  • Dave Kaminsky
    Ações de comentário Permalink

    @Dane Ross, 

    I feel your pain.  the prior comment that read-only fields "just hasn't ever been business-critical for a significant enough number of users"  seems odd, as Data consistency and hygiene is critical to any data-driven business. 

    2
  • Heather Rommel
    Ações de comentário Permalink

    I've already upvoted this but wanted to echo the continued need for more flexibility at the field level on both tickets and organizations.... We continue to have issues where we need some fields to be visible but not editable for certain Agents. We would prefer to decide this down to an Agent by Agent basis but would settle for Role and Group restrictions at the field level.  

    Allowing Agents to edit ALL fields in ALL circumstances is not a sustainable solution for any organization using Zendesk for more than one department.  We have such diversified use cases to accommodate.

    For example, internal IT would need to update certain fields while Customer Support would update different fields.  While we have leveraged forms to limit this, it doesn't really answer the security issue that it is available for edit either way.  In fact, it fails FedRAMP requirements for one thing.

    Additionally, there's no way to have forms handle the issues we're facing at a User and Organization level on read only/edit-ability.

     

    Please consider this and consider it high priority!

    4
  • Sergio Da Silva
    Ações de comentário Permalink

    I want to also consider this a high priority. I had a conversation with my colleague about how Zendesk does some great things, BUT, when we hear the "this will be added to roadmap", I cry a litte. There are a bunch of workarounds that we continually have to think about for a multitude of things in Zendesk which eventually decrease the quality of customer service with our customers. Why do we get punished?

    We have a salesforce integration and it is my understanding that it may break things so we need to be able to make certain fields read-only. 

    Come on Zendesk!

     

    1
  • Nicole - Community Manager
    Ações de comentário Permalink

    Hey Sergio - 

    Indicating that something has been added to the roadmap means that it's slated for development. Not being added to the roadmap means it's something we are not doing. 

    That being said, this is not currently being worked on, though the team is open to the idea. 

    0
  • Sergio Da Silva
    Ações de comentário Permalink

    I think I misunderstood some previous comments and now see that this isn't on the roadmap (sigh). As I understand it, features are prioritised on zendesk based on business impact and strategy. 

    I remember what Zendesk's CEO said about data http://fortune.com/2015/10/23/zendesk-ceo-this-is-where-big-data-is-heading/

    He said "The real value isn’t in storing the data; it is about interpreting the data so that it can be put to work. The Zendesk acquisition better reflects the path of where Big Data is going and how it is going to get there." Zendesk purchased BIME Analytics to conquer complexity of data. This Read only feature is one way to conquer our customer data and put it to ork. Allowing anyone to change RO data will make things more complex... 

    Also https://medium.com/zendesk-careers/zendesk-spotlight-jon-hwang-senior-engineering-manager-data-93ccd5673478 who said "...I believe data analytics is critical for the success of both our customers and the company." 

    Data is a strategic direction for Zendesk as far as I can see...

    2
  • Nicole - Community Manager
    Ações de comentário Permalink

    Hi Sergio - 

    There are many factors that go into the decisions around product development. How much engagement a particular product feedback thread in the community has is one of them, but you're correct that it's just one data point that impacts our strategic decision making.

    Part of why we tend to ask a lot of follow up questions is to evaluate things like "how business-critical is the functionality?" "Is this a common use case?" "Is what we're hearing in the community reflected in what we're hearing from customers in other channels?" 

    We also look at things like where the market and industry are going. If users are clamoring for something that's dying out in the industry, it doesn't make sense for us to invest in building it into the product, knowing it'll need to be redone in a few years. 

    I think one of the things that has changed in the ten years that our community has been live is that, when we were smaller and our products were simpler, users could post a suggestion here, devs would read it, and if it was a good idea they'd just build it into the product. As we've grown and products have become more complex, the way we use the feedback presented here has become a less direct relationship. Product managers read these threads and integrate the concerns expressed herein into their planning, but it's much more rare for them to read through a suggestion and just be able to go build the thing. 

    To speak to your thoughts on our strategic direction, many of the developments currently in process are focused on enabling customers to manage increasingly complex workflows, and to customize and expand our platforms in the ways most useful to them. This is part of why you may have seen things like the release of Zendesk Sunshine, as well as an expansion of the officially supported Zendesk Apps. Both of these enable each customer to add on the things they do need and not have the ones they don't, specific to their unique use case. 

    Much of the talk around data analytics is likely related to the release of Zendesk Explore last November. 

    Now, that all speaks to our general thoughts on product development and strategic direction. As far as this specific request, I'll ping the product team again to make sure they're aware of the issues posed here and to see if it's something they've come up with any solutions for. 

    0
  • Sergio Da Silva
    Ações de comentário Permalink

    Thanks for the update. Behind the data analytics is the actual data. I am fully invested in Zendesk as it does some wonderful things and I don't want to sound like a broken record, but if said data is not controlled and changed and a trigger action doesn't fire because it is incorrect, this can have a business impact.

    Has it ever happened? No, but our workflows are becoming more complex which means we require more robust controls. 

    Our scenario:

    We have a three way integration between atlassian statuspage (multi-tenant), Salesforce and Zendesk. Salesforce contains the customer profile (products, apps, services) which is synced with Zendesk. When the trigger is run, Zendesk sends an API call to statuspage creating subscriber with infromation from their organization profile. Our customers rely on this for critical infrastructure outages and if they don't receive a outage notification relating to their service, we don't meet out Response SLA which can cause penalties.

    Does this help?

    3
  • Michael Ohayon
    Ações de comentário Permalink

    When will this be implemented, this is a feature that would quite possibly take any developer a few minutes to add a CheckBox to make the field read-only if we chose. We are a service based business switching to Zendesk and almost done with our integration and noticed this wasn't a feature which seems disastrous for any business to not have this feature. All it takes is one employee to make a mistake and accidentally overwrite the data and my custom fields become useless. 

    I can assure you, as future businesses use the platform and need to integrate with their current system this feature is a must, not a want. I back Sergio 100% on his scenario. 

    5
  • Katie Saddlemire
    Ações de comentário Permalink

    I would like to say hear hear to adding this feature. My use case: 

    • As noted by others, there are certain fields that are populated by an integration. I'd like to prevent agents from editing these. 
    • There are specific fields that I want to make sure are required to solve a ticket, but that I don't want an agent to manually populate (instead, they should use pre-defined macros). 
    3
  • Dave Kaminsky
    Ações de comentário Permalink

    Any word here from a product manager or community manager?  There seem to be a few requests for this functionality.  Having integrated Zendesk with our other systems, agents being able to edit every field has a negative impact on data consistency that can affect multiple systems. 

    1
  • Dan Cech
    Ações de comentário Permalink

    We are running up against this same limitation in a couple of different scenarios:

    • fields that are populated via our external systems that agents should be able to see but not edit
    • fields that are populated by the customer as part of the ticket submission process that shouldn't be editable by agents
    1
  • Helen Foot
    Ações de comentário Permalink

    Is there any update on this?

    Having the ability to make fields in both ticket and organization forms read only for agents is something would save me hours of troubleshooting and fixing problems caused by overly helpful users.

    We have fields in almost every form that Agents in Group A need to edit that should be view only for Agents in Group B. Once you expand beyond a small Support department all doing the same job this becomes almost inevitable.

    We also have fields it would be super helpful to be able to hide as well as prevent people from editing - these fields are used for reporting and triggers and automations, populated by triggers, automations and integrations, and frankly cause confusion to new agents when they see them, even when placed at the bottom of forms. 

    Ideally there should be the ability to define Read, Write, View permissions for all fields (or at least all custom fields) by Group.

    This should be an essential feature for any platform that relies on data. I can't understand how anyone who uses the system can think it isn't business critical to not have permissions for fields.

    0
  • Nicole - Community Manager
    Ações de comentário Permalink

    Hi Helen -

    We have not received any updates on this from the product team.

    0
  • Dan Cooper
    Ações de comentário Permalink

    I'll add to this one.  I'd like to be able to make specific fields on the org/user profile read only and potentially hide them completely depending on what they are. 

    For my use case, I'm looking at pulling data over from our CRM platform and would like to store some of that data in Zendesk.  That data should not be updated by anyone in Zendesk, but should be readable from Zendesk.  Some of that data would ideally be hidden from most users as well so as to not clutter up the field UI on these profiles.

    In addition to having this available from the UI, I'd also like this to be accessible from the Zendesk App Framework so that an app could make a field read only today.  Hiding is available this way today, but making a field read only like they are when a user doesn't have access to edit the fields would be amazing. 

    0
  • Andrew Orner
    Ações de comentário Permalink

    I'm a brand new customer and shocked to see this capability wasn't added back when this thread started in 2013. 

    I'll echo other commentators: all of our fields are populated via our external systems that agents should be able to see but not edit. 

    0
  • Michael Ohayon
    Ações de comentário Permalink

    Andrew, you will unfortunately continue to be hit with disappointment and frustrations as you continue to use Zendesk. You will eventually see they add features that you will scour the forums and no one has ever asked for. They say they listen to the community if it gets enough hits / upvotes. However, I can assure you they aren't looking at company size / business value when making decisions on features people are asking for. They rave on how they make their platform so diverse and agile that you can integrate with everything, then I pull in data from my 3rd party systems and my team members can accidentally edit the field making that data no longer relevant. Its just a sad and unfortunately, only there are only few competitors in the space so what do we do? Second to that, switching at this point would just a nightmare once you've deployed the platform since we've created so much customization, views, etc... I can just see the headache we would have migrating elsewhere. 

    Zendesk, if you think this feature is not important since 2013. Then I envy you as you have much more intelligence than I, as security and SaaS begins to grow, data needs to be centralized and immutable. If my one system is my centralized control point and Zendesk is just a tool to help specific teams view data that is relevant to them, then they shouldn't be able to change it. So many terrible problems can happen if a team member is able to modify or mistakingly change data we put into the system. 

    Maybe one day this is an issue that will be taken seriously.. 

    1

Por favor, entrar para comentar.

Desenvolvido por Zendesk