Custom attributes without the configuration overhead

Different projects need different ways to categorize work. A software team tracks bugs by severity. A marketing team organizes content by persona. A product team groups features by strategic initiative.

Most PM tools handle this in one of two ways. Either they force you into predefined fields that don't match your work, or they make you configure custom fields through complex admin panels before anyone can use them.

PM Engine uses tags instead. Simple text labels with color. No configuration required. Add them when you need them. Organize them if you want to.

What you can track with tags

Tags capture almost any attribute you need. Here are some common examples.

Priority (and why position matters more)

Priority is one of the most requested attributes. But it's also one of the most problematic.

Different teams interpret priority differently. Some mean urgency. Others mean severity or business impact. The term itself is vague.

Priority is also time-sensitive. A high-priority task this week becomes low-priority after a product demo. But priority tags are "sticky"—teams forget to update them as context changes.

We prefer a different approach: indicate priority by position in the backlog. The order reflects intended implementation sequence. It's easy to update. It always reflects current thinking.

That said, tags still help. Instead of a generic "priority" tag, describe the specific attributes that determine priority.

Here are common ways teams define priority levels:

Impact: What happens if we don't do this?

Impact describes the effect of not implementing a card. This helps teams understand consequences, not just urgency.

Stakeholder or persona

Sometimes prioritization depends on who the work serves. A release might focus on a specific user group.

Work context

These attributes describe the type of work a card represents.

How tags work in PM Engine

Tags are text labels with color. You can add any number of tags to a card.

Tags can be project-specific or workspace-level. Project-specific tags stay within one project. Workspace-level tags appear across all projects. New tags start as project-specific by default.

You can group tags into categories. For example, a webshop project might have groups like "Work type" and "Persona."

Groups are optional. They help when you have many tags. But you can also use tags without any groups at all.

Display options

Tags can appear three ways on cards: fully displayed, as icons only, or hidden entirely. Teams adjust this based on how much visual weight tags should have in their workflow.

Filtering with tags

Tags become filters. Click a tag to show only cards with that tag. Combine multiple tags to show cards with any of the selected tags.

For more complex filtering, combine tags with other criteria. Show cards due this week but not tagged as bugs. Show cards assigned to a specific person with a particular impact level.

The filter system uses boolean logic. Match any criterion or match all criteria. Include specific tags or exclude them.

Why this works

Most PM tools treat custom attributes as a configuration problem. Create fields, define types, set validation rules, manage permissions. All before anyone can use them.

Tags skip that entirely. Someone needs to track something? Create a tag. Right now. No admin panel required.

This approach scales naturally. Small teams use a handful of tags. Larger teams create more structure with groups and workspace-level tags. The system adapts without forcing complexity upfront.

Custom attributes don't need to be complicated. They just need to capture what matters for your work.