Redmine custom fields let administrators add project-specific data to any issue type and every project has data that Redmine’s defaults do not cover. A software agency needs a “Client Name” field on every issue. A compliance team needs a “Regulatory Reference” field on change requests. A support team needs a “Customer Tier” field to prioritise tickets. A development team needs a “Story Points” field on feature issues for sprint estimation.
However, Redmine’s standard fields summary, description, assignee, priority, status, due date only cover the baseline. They do not cover the project-specific context that makes issues actionable for your workflow.
In short, custom fields solve this. They let administrators scope any field type to the exact trackers and projects that need it. This guide covers how to set them up, which field types are available, and practical examples for development teams.
The short answer: Redmine custom fields are administrator-defined data fields added to issues, projects, users, versions, or time entries. They support multiple field types text, integer, date, dropdown, checkbox, URL, and more. Custom fields can be restricted to specific trackers (Bug, Feature, Task) and specific projects, so only relevant fields appear on the right issue types. They are searchable, filterable, and reportable like any standard Redmine field.
Custom fields do not require any plugin or code change they are a built-in Redmine capability administrators configure from the Administration panel. Additionally, the Redmineflux Inline Editor Plugin extends their usability, letting team members update custom field values directly from the issue list without opening the full edit form.
Redmine supports the following custom field formats. Specifically, choosing the right format determines how the field validates input and how it appears in filters and reports.
| Format | Use Case |
|---|---|
| Text | Free-text entry — notes, references, descriptions |
| Long text | Multi-line text — acceptance criteria, test notes |
| Integer | Numeric values — story points, ticket count, version number |
| Float | Decimal numbers — estimated hours (alternative to built-in estimate) |
| Date | Date picker — review date, approval date, SLA deadline |
| Boolean (checkbox) | Yes/No flag — reviewed, approved, client-visible |
| List | Single-select dropdown — client tier, department, priority band |
| List (multiple values) | Multi-select dropdown — affected systems, test environments |
| User | Assign a user — reviewer, approver, QA owner |
| Version | Link to a Redmine version — target release, affected version |
| URL | Clickable link — ticket in external system, design file, spec document |
Create custom fields from the Redmine Administration panel. You do not need developer access only administrator access.
Go to Administration → Custom Fields → New Custom Field. Select the type of object the field applies to: Issues, Projects, Versions, Time Entries, Users, or Groups.
For most use cases, select Issues.
Fill in the field configuration:
The most important configuration step is scoping. Under Trackers, select which issue types this field should appear on. In practice, a “Story Points” field should appear on Feature issues not on Bug or Support issues.
Under Projects, either leave it global (applies to all projects) or restrict it to specific projects. For example, a “Client Name” field applies only to client-facing projects, not internal development projects.
Save the field. Open a new issue of the relevant tracker type in a scoped project. The custom field appears in the issue form immediately. Verify it shows in the correct position and behaves as expected — required validation, dropdown options, date picker. As a result, no code deployment or restart is needed.
Story points appear on Feature and Task issues for sprint estimation. In practice, combined with the Agile Board Plugin, story point totals display on sprint board views for velocity tracking without any custom coding.
Every issue in a client project is tagged with the client name. Consequently, project managers filter issues by client for billing, reporting, and cross-project visibility without needing separate Redmine projects per client.
Change requests that require sign-off track the approval date in this field. Teams filter overdue approvals using the date field in saved queries.
Links each compliance issue to the specific regulation or policy it addresses. Searchable so compliance managers can find all issues related to a specific regulation.
Support tickets from Enterprise customers are filtered and prioritised separately from Starter-tier tickets. Additionally, combined with the Helpdesk Plugin, this field supports tiered SLA rules per customer tier so high-value clients get faster response routing automatically.
Once a custom field is marked as a filter, it appears in the issue filter panel alongside standard fields. Specifically, teams build saved queries using custom field filters “Show all Feature issues with Story Points greater than 5 assigned to the current sprint” and share them as the default project view.
Similarly, custom field data appears in Redmine’s time and issue reports. The Custom Dashboard Plugin surfaces custom field metrics as dashboard widgets showing, for example, how many issues carry a specific client tag or how many compliance issues have an overdue approval date.
Redmine custom fields are administrator-defined data fields added to issues, projects, users, versions, or time entries. They support text, integer, date, dropdown, checkbox, URL, and other formats. Fields are scoped to specific tracker types and projects so only relevant fields appear on the right issue types.
Go to Administration → Custom Fields → New Custom Field. Select the object type (usually Issues), choose a format, set the field name, select which trackers it applies to, and choose which projects should show it. Save the field it appears immediately on new issues of the selected tracker type.
Yes. Custom fields marked as filters appear in the issue filter panel. You can filter, sort, and save queries using custom field values. Custom field data also appears in Redmine’s built-in reports.
Yes. When configuring the custom field, tick the Required checkbox. Redmine will block issue creation or editing until the required field is completed. Required status can be set per tracker a field can be required on Bug issues and optional on Task issues.
Yes. By default, a custom field applies to all projects unless you restrict it to specific projects during configuration. Global custom fields appear on the relevant tracker type in every project in the Redmine instance.
In short, custom fields are one of Redmine’s most underused capabilities. When configured correctly right field type, right tracker scope, right projects they eliminate the workarounds teams build with issue descriptions, free-text notes, and external spreadsheets. As a result, the data that matters for your project lives in Redmine, structured, filterable, and reportable.
