Conditions control the visibility and activity of individual elements in Leadtime project components.
They make sure that work packages, checklists, acceptance tests or questions are only shown when they're actually relevant in the respective project scenario. This keeps the project structure clear and easy to adjust.
Conditions link one element (for example, a work package) to another element that acts as a trigger.
Only when the defined condition is met—like a certain answer is given or a to-do is completed—the dependent element becomes visible.
Example:
A company creates websites with optional add-on services.
If the project indicates the customer doesn’t have their own photos, the additional work package “Photosession”—a photo shoot with a photographer—shows up automatically.
The building blocks of project components
First, create the element that should depend on a condition – for example, a work package, checklist or an acceptance test.
In the element's edit form you'll find the section “Conditions”.
There, click on “Add Condition” to create a new condition.
Choose which element controls the condition.
This can be:
A question in a work package
A to-do in a checklist
A test case in an acceptance test
Example:
Component A (Website): Question “Is there a design template?”
Component B (Blog): Work package “Design blog” will only show if the answer is “No”.
Depending on the element type, different condition types are available:
Condition | For checklist | For acceptance test | For work package | Description |
To-do is done | ✅ | ❌ | ❌ | Element appears when a task is checked off |
To-do is not done | ✅ | ❌ | ❌ | Element appears when a task is still open |
Test case passed | ❌ | ✅ | ❌ | Element appears when the test case was passed |
Test case failed | ❌ | ✅ | ❌ | Element appears when the test case was not passed |
Question is answered | ❌ | ❌ | ✅ | Element appears when the related question was answered |
Question is not answered | ❌ | ❌ | ✅ | Element appears when the question is still unanswered |
Answer contains | ❌ | ❌ | ✅ | Checks if checkbox answers contain certain values |
Answer does not contain | ❌ | ❌ | ✅ | Checks if certain checkbox values not were selected |
Answer is equal | ❌ | ❌ | ✅ | Checks if the radio button answer matches exactly |
Answer is not equal | ❌ | ❌ | ✅ | Checks if the radio button answer is different |
You can also add several conditions that all have to be met for an item to become visible.
This way, you can model complex dependencies—for example, when several questions need to be true at the same time.
Conditional questions make it possible for specific questions within a work package to only show up if a set condition has been met before.
What does that actually mean?
Not every question is always relevant for every project. Sometimes you only need certain info if a certain scenario applies. With conditional questions, you can avoid making users see too many questions that aren't relevant to them.
When is it useful?
Conditional questions come into play, when a question only makes sense, if a preceding question was answered in a certain way.
Example:
Question 1: “Have you already commissioned a hosting provider?” (Yes/No)
Question 2: “Please state your hosting provider” is only displayed if the answer to Question 1 is “Yes”.
This way, users only see the questions that are relevant to them, and the forms stay lean and easy to understand.
If conditions aren’t met, the related elements in the project tree are shown as semi-transparent.
These inactive elements are not included in the project's effort estimation.
When you click on an inactive element, the right-hand column explains why it’s deactivated.
If you’re sure you don’t need an element, you can manually remove it from the project – it will still remain in the component library.
