Question Metadata

Every question carries a set of organizational properties, set when you save it and used by the Question Bank Navigator to filter, sort, and browse your library. They overlap in purpose — all help you find questions later — but each has a different underlying structure, and that structure is what makes it suited to a different job.

Why It Matters

A bank with 50 questions is easy to scroll through by eye. A bank with 5,000 isn't — and that's exactly when these properties start paying off:

• You find the right question in seconds, not minutes — combine a folder with a tag filter (e.g. Algebra folder + difficulty: hard) instead of scrolling through hundreds of unrelated questions.
• Multiple people can work in the same bank without stepping on each other — folders keep each contributor's area separate, while status (Draft/Review/Ready) makes it obvious what's safe to use in a live test and what's still being written.
• Nothing gets lost or duplicated as the bank grows — a clear folder tree plus consistent tags means nobody accidentally writes the same question twice because they couldn't find the existing one.
• You can run a multi-language program from one bank — language tagging lets you filter to just the questions for a given locale instead of maintaining separate banks per language.
• Reporting and audits become possible — tags and folders give you a consistent vocabulary to slice results by (e.g. "how did candidates do on hard Algebra questions specifically"), which a pile of untagged questions can't support.

Which One Should You Use?

Each property's structure isn't arbitrary — it's what makes it suited to a different job:

• Folder — the question's single, structural home. Because it's a tree, it's exclusive and hierarchical: a question lives in exactly one place, which makes bulk actions and scoping natural (export "everything under Math", hand a whole sub-folder to one contributor). Use it when a question belongs to one clear place in a hierarchy — no other property lets you act on a whole branch at once.
• Tags — structured key-value attributes a question can carry several of at once (difficulty: hard, topic: algebra). Because each tag has both a dimension and a value, the navigator can run precise multi-condition queries across dimensions that don't fit a single tree. Use tags when you need combinable filters, like difficulty and topic together.
• Labels — free-form, no-key markers (needs review, exam-ready). Because they're flat strings with no key, they're fast and frictionless — no taxonomy to design up front. Use labels for ad-hoc or temporary flags you want to add and remove without deciding what "dimension" they belong to.
• Language — a single ISO code marking what language the question is written in. Because it's one fixed value from a known list rather than free text, filters and integrations can rely on it without guessing at spelling. Use it only if your bank serves more than one language.
• Status — where a question sits in your team's review workflow (Draft / Review / Ready). Because it's a small ordered set, it models a workflow the way a plain label couldn't — Draft → Review → Ready mirrors how a team actually reviews work. Use it to track progress, not to restrict usage — a Draft question can still be added to a test.

Reach for a folder first when deciding how to organize a new bank — it is the one property every question must have, and getting the tree right early saves a lot of tag cleanup later. As your team grows, see Schema Enforcement (on the Question Bank Overview page) to lock folder and tag naming down and prevent drift.

Good to know