See related

Attribute level permissions

Last Update: Oct 2024 • Est. Read Time: 3 MIN
To check plan availability, see the pricing page.

Attribute level permissions lets you define the level of access a user in your organization will have to a specific attribute in both standard and custom objects. With attribute level permissions, you can prevent a user from seeing or possibly changing certain information, such as a customer's email address. 

Who can access this feature?
User typesAdmins can access the Permissions sets page.


In this article

Changing a user's access to an attribute

You can control whether a user will be able to view or edit a particular attribute on an object. You can customize the level of access users will have to both standard and custom attributes.

Note: Removing a user's Read access will automatically remove their edit access as well.

  1. Go to Settings > Users > Permission Sets.
  2. Create a new permission set or edit an existing one. 
  3. Select Object Permissions and then an object. In this example, we are going to edit the permissions for the Customer object.
  4. Select the Attribute Permissions tab. Here, you will see a list of all of the attributes in the Customer object. By default, users will have access to all of the attributes in an object for which they have access.
    Note: Attributes that are heavily relied on in multiple areas of the platform, such as company and customer name, cannot have read access removed.
  5. Customize access to a specific attribute by selecting the Read or Edit checkboxes for it.
  6. Once you are done making your changes, select Save Changes.

Restricted attributes and search

Any access changes you make to attributes will also affect if a user can see it when:

  • Performing searches (global, merging customers, or moving conversations).
  • Creating a bulk action.
  • Creating an export.

When a user with attribute level permissions uses global search, merge customer search, and move conversation search, they may see companies, customers, conversations, and custom objects (kobjects) returned that have an attribute value that they do not have access to read. This is because these searches take all attributes into account when searching. However, if a user doesn't have read access to that attribute, it will be hidden from the search results or when viewing the object in Kustomer. 

For example, let's say you have removed a user's read access to customer external IDs and they build a search query using an external ID such as, Customer Any Text is equal to ts123, the search will return the customer named Tom Smith and exclude the external ID attribute.

If a user doesn't have read access to an attribute, they also won't be able to select it as a property when building a search query. Using the previous example, the user also won't be able to select External ID when using the search query builder.

You can prevent users from using any of these searches using permission sets.

Restricted attributes and shortcuts

If a user tries to use a shortcut in a draft and they don't have access to an attribute used in the shortcut, the shortcut won’t be available for them to select.

Required Conversation attributes

When adding attributes to the Conversation klass, you have the option of defining it as a required attribute that must be filled out before a conversation can be marked as Done. To ensure that agents don't find themselves in a situation where they can't close a conversation, attributes that are marked required can't have its permission set edited, and you cannot remove read or edit access for them.