Read-only custom org/user fields

26 コメント

  • Craig Hamm
    コメントアクション 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
    コメントアクション Permalink

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

    2
  • Everett Griffiths
    コメントアクション Permalink

    +1.  Far too easy to accidentally delete data.

    2
  • Ludovic Garcia
    コメントアクション 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 R
    コメントアクション Permalink

    yes!!!

    +1!!!

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

    3
  • Lionel Laffineur
    コメントアクション Permalink

    Any update here ?

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

    2
  • Sheldon Dickinson
    コメントアクション Permalink

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

    0
  • Chris Hall
    コメントアクション Permalink

    +1 please :)

    0
  • Mindaugas Verkys
    コメントアクション Permalink

    +400

    0
  • Dan Ross
    コメントアクション 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
    コメントアクション Permalink

    Thanks for sharing, Dan. 

    0
  • Dave Kaminsky
    コメントアクション 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
    コメントアクション 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
    コメントアクション 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
    コメントアクション 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 R
    コメントアクション 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
    コメントアクション 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
    コメントアクション 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
    コメントアクション 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
    コメントアクション 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
    コメントアクション 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
    コメントアクション 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
    コメントアクション 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
    コメントアクション 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
    コメントアクション 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
    コメントアクション 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

ログインしてコメントを残してください。

Powered by Zendesk