Using conditional logic in check-ins

Not every question in a check-in is relevant to every person every day. Conditional logic solves this by making your check-ins adaptive. Instead of asking everyone the same fixed sequence of questions, you create branching flows where follow-up questions only appear when they’re triggered by a specific answer.

The result is shorter, more focused check-ins for most people, and deeper information from the people who need to share it. Someone who isn’t blocked doesn’t need to explain a blocker. Someone who hit their goals doesn’t need to explain why they fell short. Conditional logic makes this automatic.

How conditional logic works

Every question in a check-in has a logic setting. By default, it’s set to “Always,” which means the question shows up regardless of previous answers. To make a question conditional, you change this setting to reference a previous question and define a trigger condition.

When a team member answers a question that has a condition attached to the next question, Dailybot evaluates the answer against the trigger. If the condition is met, the follow-up question appears. If not, Dailybot skips it and moves to the next question in the sequence. The team member never even sees the skipped question.

Setting up your first conditional flow

Start by creating a check-in with at least two questions. Once your questions are in place, click “Show logic” on the question you want to make conditional. You’ll see the logic editor where you can reference a previous question and define the trigger.

For example, suppose your check-in starts with “Do you have any blockers?” (a yes/no question) followed by “Please describe the blocker and who can help” (an open-ended question). You’d set the logic on the second question to: show this question only when the answer to question 1 “is equal to” Yes. Now, team members who answer “No” to the blocker question skip the description entirely and move straight to whatever comes next.

Available trigger conditions

Dailybot gives you several operators to define when a question should appear. Each one compares the previous answer against a value you specify.

• Is equal to: The answer must match your value exactly. Best for yes/no and multiple choice questions.
• Is not equal to: The answer must be different from your value. Useful for “show this unless they chose X” scenarios.
• Contains: The answer must include the specified text somewhere. Works well with open-ended responses where you’re looking for a keyword like “blocked” or “help.”
• Not contains: The answer must not include the specified text.
• Begins with / Not begins with: Checks the start of the answer.
• Ends with / Not ends with: Checks the end of the answer.

Yes/no and multiple choice questions work best with “is equal to” and “is not equal to” because the answers are predictable. Open-ended questions pair well with “contains” and “not contains” since you’re matching against keywords in free text.

Controlling the flow

When a condition is met, you decide what happens next. You have two options: proceed to the next question in the sequence, or end the check-in immediately. Ending the check-in is useful when certain answers make the remaining questions irrelevant.

You can also set a fallback rule that defines what happens when none of your conditions match. This ensures every possible answer path is handled gracefully, even if someone gives an unexpected response.

One important constraint to keep in mind: conditional logic only moves forward. You can skip ahead to a future question or finish the check-in, but you can’t go back to a previous question. Design your question order with this in mind, and place branching questions early so the conditional follow-ups flow naturally from there.

Practical examples

Blocker detection: Start with “Are you blocked on anything?” (yes/no). If yes, ask “What’s blocking you and who can help?” If no, skip to the next topic. This keeps unblocked people moving fast while capturing critical information from blocked ones.

Escalation triggers: Ask “How confident are you about hitting this week’s goals?” (numeric, 1-10). If the answer is below 5, trigger a follow-up: “What’s putting the goal at risk?” This gives you an early warning system without burdening confident team members.

Conditional mood check: After the standard standup questions, ask “How are you feeling today?” (scale). If the score is 3 or below, ask “Is there anything the team can do to help?” This creates a safety net that only activates when someone is having a rough day.

Best practices

Keep your conditional trees simple. One or two branches per check-in is usually enough. Complex logic with many nested conditions becomes hard to maintain and confusing for respondents if they notice different people getting different questions.

Test your flow before rolling it out. Answer the check-in yourself with different responses to make sure the branching works the way you expect. Pay special attention to edge cases where someone might give an unexpected answer.

Dailybot lets you edit conditional logic at any time, so you can start simple and refine the flow as you learn what your team needs. The goal is check-ins that feel personal and relevant to each team member, without adding any extra work for you.