By default, a custom field shows up on every record of the entities it is attached to, and everyone who opens those records sees it. This article shows how to limit a custom field to specific records, and how to choose who sees its value and who can change it.

💡 Who is this for? Account Admins who create and manage custom fields. The last section explains what Project Managers, Vendors, Clients and other users see once a field is restricted.

Before you start

Requires Account Admin access. Only Account Admins can open Settings > Account > Custom fields and change where a custom field applies and who can see or edit it.
This article assumes you know how to create a custom field. If not, start with All About Custom Fields.

Key concepts

Setting	What it controls	Left empty
Entity settings	Which records the field appears on (for example, only projects of one Organizational Unit).	The field appears on every record of the selected entities.
Visibility	Who sees the field and its value.	Everyone sees the field.
Value editing	Who can fill in and change the value.	Account Admins and Project Managers who see the field and can update the record can edit it. Other roles cannot.

An Organizational Unit is a group of projects, users and settings inside your account, usually one per client or department. See All about Organizational Units.

How the rules combine

Each setting can hold several values, and the same logic applies to all of them:

Within one list, any value matches. If User roles lists Project Manager and Vendor, a user with either role matches.
Across lists, every list that has values must match. If Org. unit members lists Acme Legal and User roles lists Project Manager, only Project Managers who are members of Acme Legal match.
Excluded users never match, even when they meet every other condition.

ℹ️ Note: "Member of an Organizational Unit" means the user is linked directly to that Organizational Unit. Being an Account Admin, or being linked to its Organization, does not make a user a member.

Step 1: Open the custom field

Go to Settings > Account > Custom fields.
To change an existing field, click ⋯ at the end of its row and choose Edit. To create a new one, click Add field.
In Entity Select, choose the entities the field belongs to. The Entity settings section only shows the options that apply to the entities you choose here.

Create Custom Fields form with Project selected in Entity Select, highlighted, above the collapsed Entity settings and Permission settings sections

Step 2: Limit the records the field appears on (Entity settings)

Expand Entity settings. The options depend on the entity:

Entity	Option	Effect
Organization	Organization	The field appears only on the organizations you select.
Org. Unit	Org Unit	The field appears only on the Organizational Units you select.
Glossary	Glossary	The field appears only on the glossaries you select.
Translation Memory	Translation Memory	The field appears only on the translation memories you select.
User	Org. unit members, User roles, Exclude users	The field appears only on the profiles of users who match.
Project, Task, Payable, Receivable	Records in Org Units	The field appears only on records that belong to the Organizational Units you select.

When the field belongs to more than one of Project, Task, Payable and Receivable (or to All Entities), Records in Org Units also shows Record types, so you can keep the field on projects but off tasks, for example.

Entity settings expanded for a Project field, with one Organizational Unit selected under Records in Org Units

ℹ️ Note: A field with Entity settings cannot be used as a filter in record lists (for example, the project list filters). This keeps a filter from revealing values on records where the field does not apply.

Step 3: Choose who sees the value (Visibility)

Expand Permission settings. Under Visibility, add the users who should see the field:

Org. unit members: members of the Organizational Units you select.
User roles: users with the roles you select.
Exclude users: users who never see the field, even if they match the other two lists.

Leave all three empty to show the field to everyone. Whoever is allowed to edit the value (Step 4) also sees it, even if they are not listed here.

Permission settings expanded: Visibility (step 3) limited to the Account admin and Project manager roles, and Value editing (step 4) limited to Project managers who are members of one Organizational Unit

⚠️ Warning: These rules also apply to the API. If an integration reads or writes this field, include the user the integration signs in with, or the field disappears from its responses and its updates are refused.

Step 4: Choose who can change the value (Value editing)

Under Value editing, the same three lists decide who can fill in and change the value:

Left empty, Account Admins and Project Managers who see the field and can update the record can edit it. Every other role sees the value as read-only.
Once you add Org. unit members or User roles, only users who match can edit the value, Account Admins and Project Managers included.
Exclude users removes the right to edit from the users you select.

Value editing only controls the value on each record. It does not change who can edit the custom field itself in Settings.

Click Save.

Step 5: Check the Scope column

Back in Settings > Account > Custom fields, the Scope column summarizes each field's settings:

All records: the field has no Entity settings and appears on every record of its entities.
A chip with a name (an Organizational Unit, glossary, organization…): the records the field is limited to.
A lock icon: the field has Visibility or Value editing rules.

Custom fields list with the Scope cell of the Cost center field highlighted, showing an Organizational Unit chip and a lock icon, while other fields show All records

Click Filters to search the list by name, data type, entity, value, Entity settings or Permission settings. The Filters button shows how many filters are active; click Clear all filters to remove them.

Worked example

Your client Acme sends legal projects through the Acme Legal Organizational Unit and wants a Cost center code on each project. Only Project Managers and Account Admins should see it, and only the Project Managers who handle Acme Legal should fill it in.

Setting	Value
Entity Select	Project
Entity settings > Records in Org Units > Org Units	Acme Legal
Visibility > User roles	Project Manager, Account Admin
Value editing > Org. unit members	Acme Legal
Value editing > User roles	Project Manager

The result:

User	Sees Cost center	Can edit it
Project Manager, member of Acme Legal	Yes, on Acme Legal projects	Yes
Project Manager, not a member of Acme Legal	Yes, on Acme Legal projects	No
Account Admin	Yes, on Acme Legal projects	No: Account Admin is not in the Value editing roles
Vendor or Client	No	No
Anyone, on a project of another Organizational Unit	No: the field does not apply there	No

To let Account Admins fill in the code too, add Account Admin to Value editing > User roles.

What other users see

Once a field is restricted, users who open a record see one of three things:

The field does not appear when the record is outside the Entity settings, or when the user is not allowed to see it. Nothing on the record says a field is hidden.
The field appears disabled when the user can see it but cannot edit it.
The field appears editable when the user can edit it.

This applies to every role: Project Managers, Vendors and Clients see custom fields on the records they can open (projects, tasks, their own profile), filtered by these rules.

Common mistakes

Restricting Value editing and locking out admins. Once Value editing has a role or Organizational Unit, Account Admins and Project Managers lose their default right to edit. Add their roles if they still need it.
Expecting Account Admins to count as members. An Account Admin who is not linked to an Organizational Unit does not match Org. unit members, so a Visibility rule based only on Organizational Units hides the field from them.
Combining lists when you meant "either". Org. unit members and User roles must both match. To give access to "members of Acme Legal or any Project Manager", you cannot do it with one rule. Use User roles alone, or Org. unit members alone.
Forgetting integrations. A restricted field disappears from API responses for users who cannot see it.

Troubleshooting

"You are not allowed to change one of these custom fields. Reload the page to see the current values." Your permissions for a field changed while the record was open. Reload the page; the field now shows as disabled or is hidden.
A field disappeared from a record. Check the field's Entity settings (the record may be outside them) and its Visibility.

How to limit where a custom field applies and who can see or edit it