Skip to content
Leadtime
English
Esc
navigateopen⌘Jpreview
On this page

Conditions in Work Packages

Conditions control which elements of a project component are visible or active. They link questions, to-dos, or test cases to enable dynamic, context-dependent project structures.

Conditions control the visibility and activity of individual elements in Leadtime project components.

They ensure that work packages, checklists, acceptance tests, or questions are displayed only when they are actually relevant to the current project scenario. This keeps the project structure clear and flexible.

How it works

Conditions link one element (such as a work package) to another element that acts as the trigger.

The dependent element becomes visible only when the defined condition is met—for example, when a specific answer has been provided or a to-do has been completed.

Illustration

Example:

A company creates websites with optional additional services.

If the project indicates that the customer does not have their own photos, the additional “Photo session” work package—a photo shoot with a photographer—appears automatically.


How to create a conditional work package

The building blocks of project components

Illustration

1. Create the element

First, create the element that should depend on a condition—for example, a work package, checklist, or acceptance test.

2. Add a condition

In the element’s edit form, find the “Conditions” section.

Click “Add Condition” to create a new condition.

3. Define the target element

Select the element that 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

[!INFO] Conditions can also work across components—a work package in component B can therefore depend on an answer in component A.

Example:

  • Component A (Website): Question “Is there an existing design template?”
  • Component B (Blog): The “Design blog” work package is displayed only when the answer is “No.”

4. Select the condition type

Different condition types are available depending on the element type:

Condition For checklist For acceptance test For work package Description
Todo is done check_mark_button cross_mark cross_mark The element appears when a task has been checked off
Todo is not done check_mark_button cross_mark cross_mark The element appears while a task is still open
Test case passed cross_mark check_mark_button cross_mark The element appears when a test case has passed
Test case failed cross_mark check_mark_button cross_mark The element appears when a test case has not passed
Question is answered cross_mark cross_mark check_mark_button The element appears when the related question has been answered
Question is not answered cross_mark cross_mark check_mark_button The element appears while the question is unanswered
Answer contains cross_mark cross_mark check_mark_button Checks whether checkbox answers contain specified values
Answer does not contain cross_mark cross_mark check_mark_button Checks whether specified checkbox values were not selected
Answer equals cross_mark cross_mark check_mark_button Checks whether a radio button answer matches exactly
Answer does not equal cross_mark cross_mark check_mark_button Checks whether a radio button answer differs

5. Combine multiple conditions

You can also add multiple conditions that must all be met before an element becomes visible.

This allows you to model complex dependencies, such as scenarios in which several questions must meet their conditions at the same time.


Conditional questions

Illustration

Conditional questions make it possible for specific questions within a work package to appear only after a defined condition has been met.

What does this mean in practice?

Not every question is relevant to every project. Some information is needed only when a particular scenario applies. Conditional questions prevent users from seeing unnecessary questions that do not apply to them.

When should you use them?

Use conditional questions when a question is relevant only if a preceding question was answered in a particular way.

Example:

  • Question 1: “Have you already hired a hosting provider?” (Yes/No)
  • Question 2: “Please enter your hosting provider” is displayed only if the answer to question 1 is “Yes.”

As a result, users see only the questions relevant to them, keeping forms concise and easy to understand.


Inactive elements

Illustration

When conditions are not met, the related elements are shown semi-transparent in the project tree.

These inactive elements are not included in the project’s effort estimate.

Clicking an inactive element displays an explanation in the right-hand column of why it is disabled.

If you know that an element is not required, you can remove it from the project manually—it remains available in the Component Library.

Was this page helpful?