Scope custom fields to one project

Pro plan Project Member

Most custom fields don’t belong on every project. An “Acceptance Criteria” field is precious on a delivery project and noise on a marketing campaign; a “Compliance Region” matters in the regulatory program and is invisible elsewhere. Project-scoped custom fields solve this without forcing every field through the org admin: the project’s own managers can add what their work needs, and the org grid stays clean. Promote the genuinely useful ones to org-wide later, when they’ve earned it.

Who can create them

Project Owners and Managers can create fields for their own project, without involving an organization admin. Org admins can manage them too. This is the key difference from organization-wide fields, which need the organization-level permission: scoping the blast radius to one project means the project’s own managers can be trusted with the decision.

Create a project-scoped field

Open the project, go to the Settings section, and select the Fields tab. It lists the task fields scoped to just this project.
Select the add-field button, name the field, and pick its type. For Dropdown and Multi-select types, enter the options, one per line.
Save. The field now appears on this project’s tasks and as an available column in this project’s Grid view, and nowhere else.

In the Grid view’s column picker, fields are grouped under two headings so you can always tell which is which: organization fields, available across every project, and project fields, scoped to this one.

Promote a field to organization-wide

When a project-scoped field proves broadly useful, an organization admin can promote it from the same Fields tab using Promote to org-wide. After promotion the field appears on every project’s forms and Grid, and every value already entered stays attached.

Promotion is deliberately admin-only, even though project managers can create the field in the first place: making a field visible everywhere is an organization-level decision.

Best practices

Default to project-scoped; promote only when earned. Most fields you can imagine adding belong inside one project. The discipline of starting project-scoped keeps the org-wide field list short and the Grid view scannable. Promotion is one click when the field genuinely matters across projects.
Use project scope for imported MS Project columns by default. Onplana already does this automatically (.mpp ExtendedAttributes arrive project-scoped), so you don’t have to think about it on import. Promote the ones worth keeping afterward; ignore the rest.
Name project-scoped fields without the project’s name prefix. “Region” inside a project is fine — the scope already implies it belongs to that project. “Acme Region” is redundant; “Region” on Acme’s Grid view reads cleanly enough.
Demote fields you no longer need rather than deleting them. Org-wide field promotion is one-way today. If a field stops being useful, change its name to “[Deprecated] X” or hide it from the form rather than deleting it — that way historical data stays attached.

Troubleshooting / common pitfalls

The Fields tab in the project’s Settings is empty. That means no project-scoped fields exist yet. Org-wide fields managed at Organization Settings → Custom Fields don’t appear here; they appear directly on the task form. Project- scoped fields are an opt-in addition.
I can’t see the “Promote to org-wide” button. Promotion is org-admin only. As a Project Manager you can create and manage the field within the project; promoting it requires an Organization Admin or Owner. Ask one of them.
My imported field is duplicated across projects. Each import creates project-scoped versions, so importing the same .mpp template into three projects gives you three independent “Cost Center” fields. Promote one to org-wide before importing again; the import flow then reuses the org- wide field instead of creating new ones.
I deleted a project-scoped field that had values. Onplana blocks deletion while values exist on tasks. If the delete succeeded, the field had no values — re-add it if you need it back, then bulk-fill from the Grid view.
Promotion made the field appear elsewhere but the existing values are missing. Values bind to the field’s id, which is preserved through promotion. If existing tasks show empty values, two causes: (a) the tasks were created after the field was deleted and re-created (resulting in a new field with the same name but a new id), or (b) the values were cleared before promotion. The Recycle Bin doesn’t track custom field value changes.

How this combines with other features

Project-scoped + Grid view. The Grid is the canonical surface for editing project-scoped field values across many tasks at once. Bulk-edit a column, save, and the values propagate. Org-wide and project-scoped fields are visually separated in the column picker so you can tell at a glance which is which.
Project-scoped + Import. The import flow defaults to project-scoped for MS Project ExtendedAttributes. If you re-import an updated .mpp of the same project, Onplana reuses existing fields by name when possible instead of creating duplicates.
Project-scoped + Promotion. Promotion is the bridge from “this one project needs it” to “every project should have it”. Promotion is one-way today — promoting a field can’t be reversed back to project-scoped without manual recreation, so promote deliberately.
Project-scoped + Reports. Project-scoped fields don’t appear in cross-project Reports (because they only exist on one project). To roll up data across projects, promote the field to org-wide first.

Coming from another tool

Tool	Mapping
Microsoft Project ExtendedAttributes	Direct: imported as project-scoped by default
Asana custom fields	Asana has team-level and project-level fields; project-level ≈ project-scoped here
Jira custom fields	Jira’s “project scope” ≈ project-scoped; “global scope” ≈ org-wide here
Notion database properties	Notion properties are always database-scoped; the closest analog is project-scoped fields on a single project
ClickUp Custom Fields	ClickUp’s “Available in this Folder/Space” ≈ project-scoped here

FAQs

Can I edit everything about a field from the project’s Fields tab? The project-level manager is intentionally lean: name, type, and options. If a field needs the full editing surface (description, default value, required flag), promote it to org-wide and manage it in Organization Settings.

Can I delete a project-scoped field? Yes, as long as no values have been entered against it. Once tasks carry values, deletion is blocked so data cannot be silently destroyed.

What happens to the data when a field is promoted? Nothing is lost. Values bind to the field itself, not to its scope, so everything entered while the field was project-scoped remains attached and visible after promotion.

Can a project-scoped field be reverted back to project-scoped after promotion? Not through a single UI action today. Promotion is treated as deliberate. If you genuinely need to re-scope a field, the cleanest path is to create a new project-scoped field with the same name and bulk-migrate values, then delete the org-wide one.

Why do I see “Project fields” and “Organization fields” headings in the Grid column picker? The Grid groups custom fields by scope so you can tell at a glance which apply to every project (org) vs only this one (project). The groupings reduce confusion when a project has both kinds.

Can I create project-scoped fields on proposal entities, not just tasks? Today the project-scoped flow covers tasks. Project- and proposal- scoped fields can also be created from Organization Settings; the project’s Fields tab is the lightweight surface for the common task-scope case.

Does importing the same .mpp file into two projects share their custom fields? No. Each import creates project-scoped fields for that import. To share fields across imports, promote one to org-wide first; subsequent imports then reuse the org-wide field instead of duplicating it.

Create custom fields — the org-wide custom-field flow
Import a Microsoft Project file — sources project-scoped fields by default
Run cross-project reports — why promotion matters for cross-project rollups

Was this helpful?