PRIORITY | FAQ | How to find where else is a custom field used?

Finding where a custom field is used

How to check which custom types and which forms a field appears on, before you change it

Contents

• 1. Introduction & Context
• 2. Key Features & Functions
• 3. Requirements
• 4. Step-by-Step Guide
  • Finding the field
  • Reading the Custom Type Settings
  • Syncing the schema after a change
• 5. Common Issues & Troubleshooting
• 6. Related Articles

1. Introduction & Context

Custom fields let you add your own fields to the standard ones. A field is created against a single module, and within that module it can be scoped to particular custom types, so it might appear on an Audit Action but not on a Treatment Action.

That scoping is why the question comes up. Before you rename a field, change its type or switch it off, you need to know where it is currently in use, because a change lands on every custom type and every form it is enabled for. All of that is held in one place on the field itself, in the Custom Type Settings section.

A worked example. A team wants a field label changed from Review to Audit in their HSE audits, and wants to be sure the change lands there and nowhere else. Opening the field and reading Custom Type Settings answers that in one screen: every custom type the field is enabled for is listed, so you can see whether anything outside HSE audits would be affected before you touch it.

Who is it for? System administrators. Both finding a custom field and changing one need system administrator permissions.

What does it impact? Anywhere the field is enabled, which can include the new form, the edit form, the mass edit form, the show view and mobile. Changes do not reach the forms until the schema has been synced.

2. Key Features & Functions

• Fields belong to a module: a custom field is created against one module and does not cross into others.
• Scoped to custom types: within that module, the field is switched on or off for each custom type individually.
• Controlled per form: for each custom type, the field can be shown on the new form, edit form, mass edit form, show view and mobile independently.
• Custom Type Settings is the single source of truth: one table on the field shows every custom type and where the field appears for each.
• Searchable list: the Custom Fields page has a search panel and filters, so you can find a field by name rather than scrolling.

3. Requirements

• System administrator permissions. Required both to add a custom field and to see where one is used.
• Access to the schema for the module, since any change you make has to be synced before it reaches the forms.
• The module and custom type names the field relates to, which makes it much quicker to find in the list.

4. Step-by-Step Guide

Finding the field

1. Go to Admin, then Custom Fields.
2. Use the search panel to find the field you want to review. The list shows its ID, type and module alongside the title.
3. Click Edit, the pencil icon in the Actions column, to open the field. There is also an Edit button in the top-right corner once the field is open.

Searching the Custom Fields list narrows it to the fields whose titles match.

The edit icon in the Actions column opens the field directly from the list.

Reading the Custom Type Settings

1. Scroll down to the Custom Type Settings section.
2. Each row is a custom type in that module. The Enabled toggle shows whether the field applies to that type at all.
3. For the types that are enabled, read across the row to see which forms the field appears on.
4. That row-by-row picture is the answer to where the field is used. In the example below only one custom type is enabled, so the field appears nowhere else.

Custom Type Settings, with a row per custom type and a column per form.

Syncing the schema after a change

If you change the field while you are in there, the change does not reach the forms on its own.

1. Go to Admin, then Schemas.
2. Look for a yellow bar across the top of the page saying the schemas are out of sync. That bar is how you know a change is waiting.
3. Click Sync Schemas.
4. Reload the form and check the field looks the way you intended.

5. Common Issues & Troubleshooting

Best practices:

• Check Custom Type Settings before changing a field, not after. It is the only place that tells you how far the change will reach.
• Sync the schema as part of the change, not as a separate job later. Most of the confusion around custom fields comes from the gap between the two.
• Give fields titles that say which area they belong to, so they are findable by search when there are hundreds of them.
• Enable only the forms you actually need. Switching a field on everywhere makes the forms longer for everyone.
• Check a real record of each affected type after syncing, rather than assuming the settings had the effect you intended.

6. Related Articles