If you administrate Jira today, a good part of your week might go into using schemes in order to create new projects or maintain projects. Which issue types exist in a project, which workflow each one follows, which fields show up on which screen, and which of those fields are required. Each of those lives in its own scheme, maintained globally, and then mapped onto projects. So, as a Jira admin you might know the pain that a project-specific change to an issue type means touching a scheme that’s shared across your whole instance or building a duplicate scheme just to isolate one project’s needs.
Everything below walks you through how the concepts you already manage in Jira, like issue types, workflows, screens, and field configurations map onto a new model in OpenProject.
If you’re a current OpenProject admin, this is a big chance for you too even though you’ve never dealt with Jira’s scheme model. Today, a work package type’s fields and workflow are configured once and apply the same way to every project that has that type enabled.
With our new configuration model, workflows and forms become standalone objects. You define them once, give them a clear name, and use them in as many types and variants as you need. Variants are a new concept, that lets you create versions of a type with small changes to its settings. Your existing types keep working exactly as they do today and nothing in your current setup changes automatically.
Important
This feature is planned for OpenProject 18.0, scheduled for December 2026. Please note that this article is a preview. The functionality and screenshots shown here are subject to change before the final release.
Speaking both languages
Before we get into it, a quick translation of terms.
| Jira | OpenProject |
|---|---|
| Issue type | Work package type |
| Issue type scheme | Types and variants enabled per project |
| Workflow scheme | Workflow, used by types and variants |
| Screen scheme / issue type screen scheme | Form, used by types and variants |
| Field configuration scheme (mandatory fields) | Field visibility and required fields per type or variant |
Our vision: Workflows and forms as standalone objects
We believe admins shouldn’t have to choose between consistency and flexibility. That’s the vision behind our new concept. Today, a workflow in OpenProject belongs to exactly one type. From version 18.0 on, a workflow is an object of its own and so is a form (meaning which fields appear on a work package). Both can be created and configured in your settings under “Work packages”.
Preview of OpenProject 18.0: The new workflow and form libraries provide central overviews of reusable workflows and forms, including their assigned types, variants and projects.
Let’s say your organization uses one approval workflow for Change Requests, Purchase Orders and Contracts. You create the workflow “Manager approval” once and use it in all three types. When the approval process changes, you edit the workflow in one place, and every type using it picks up the change immediately.
Two ways to set up a workflow or form
When you configure the workflow or form of a type or variant, you choose between:
Option 1: Use an existing workflow or form
Pick one that already exists in your instance. It stays connected, so any change to it applies everywhere it is used. This is what makes maintenance at scale fast.
Preview of OpenProject 18.0: When configuring a type variant, administrators can use an existing workflow or configure a new one for the variant.
A workflow you pick this way is read-only on the type or variant, which is why the transitions appear greyed out (image above). Any change you make to the shared workflow applies everywhere it’s used. If you need a different version for just this type or variant, choose option 2.
Option 2: Configure a new workflow or form
Build a workflow or form of its own. You can start with a copy of an existing workflow or form and edit from there or you start from scratch. Once saved, it’s a new object that you can use in other types and variants too.
Preview of OpenProject 18.0: A new workflow can be based on a copy of an existing workflow or created from scratch.
Form: Field visibility and required fields
Using an existing form doesn’t mean every field has to behave the same way everywhere. You can:
- Switch fields on or off for a specific type or variant, so each one only shows the fields it needs.
- Make a custom field required for a type. Its variants pick that up automatically, and you can still make the field optional in a single variant. For example, a field required on a Type “Bug” stays required in a variant “Bug Hardware”, while variant “Bug Software” can make it optional.
The form itself stays untouched, so your changes affect only that one type or variant.
Preview of OpenProject 18.0: Type variants can reuse an existing form or have their own form configuration, including which fields are displayed.
To keep an overview you have all workflows and forms in one place. The workflow and form libraries list every workflow and form in your instance, which types and variants use it, and how many projects it’s active in. Before building something new, you see right away whether a fitting one already exists.
Preview of OpenProject 18.0: The workflow library provides an overview of reusable workflows and shows where they are used across types, variants, roles and projects.
Where Type Variants come in
Shared workflows and forms become especially useful together with Type Variants.
Take “Bug” as an example. Your hardware team and your software team both track bugs, but they follow different processes and need different fields. Instead of creating two unrelated types, you create “Bug Hardware” and “Bug Software” as variants of the parent type “Bug”. Each variant can use the parent’s workflow and form, pick another existing one, or configure a new one.
Each project uses one variant of a type at a time. In your hardware project, “Bug” follows the hardware process, and in your software project, it follows the software process. Because both variants share the type name “Bug”, you can still group and filter all bugs together on a global level, no matter which variant they use.
Preview of OpenProject 18.0: Variants allow administrators to create different configurations of a work package type for specific use cases.
Other setting like Defaults and PDF export
Other settings of a variant, such as the Defaults (default description text), Project attributes, and Generate PDF (PDF export template) are not standalone objects. For these, a variant either uses its parent type’s setting or you configure it manually. By “setting,” we mean any individual piece of a type’s configuration that can be set independently.
Preview of OpenProject 18.0: Work package type settings bring together the configuration of variants, forms, workflows and other type-specific options.
Who gets to create variants
Instance admins can decide per type whether project admins can create and manage their own variants. For each type, a checkbox controls this. If it is enabled, project admins can create variants for that type and those variants are only available in their project. If it is not, the type stays centrally managed. This way, large organizations can delegate the work without losing oversight. A global admin can keep a type’s behavior shared and centrally maintained, while still allowing changes that differ per project.
As a project admin, you see for each type its variants, which of them are in use in your project, and whether you have permission to create or edit your own variants.
Preview of OpenProject 18.0: Project administrators can see the available work package types and their variants and add project-specific variants.
What’s next
Shared workflows and forms are part of our broader “Workflows & automations” work, alongside topics like “Workspace foundations” and improvements for agile ways of working, as we build out OpenProject as a self-hostable alternative for teams leaving Jira Data Center.
As always, we’d love to hear from you.
