Using NPS Conversation Logic to Control Flow

NPS Logic controls how your NPS behaves during a response. Where the NPS Designer tab defines what questions appear and what they look like, NPS Logic defines which questions appear for which respondents and what each respondent sees after they submit. This is where you make Promoters, Passives, and Detractors have different experiences inside the same NPS.  See our worked examples and recommended actions here too!

For the rest of the NPS builder, see Building and Configuring an NPS Conversation. For background on what NPS is, see Understanding Satisfaction and NPS in Oomiji.

Opening the NPS Logic Tab

NPS Logic lives as the third tab in the NPS builder, alongside NPS Designer and Test NPS. To reach it:

  1. Click Satisfaction in your toolbar.
  2. In the top right of the Satisfaction Metrics card, click the three-dot overflow menu and select Edit.

On the Reconfigure NPS screen, click the NPS Logic tab.

Reading the Rules Table

The NPS Logic tab displays your existing rules in a table with two columns: Condition(s) and Action(s). Each row is one rule. A pencil icon on the left edits the rule, and a red X on the right deletes it. An Add New button above the table opens the rule editor for a new rule.

Each rule reads as a simple sentence: when the condition is true, perform the action. The example rule “{nps_score} > 8 → Show custom text for the 'Thank you page'” means: when a respondent scores a 9 or 10, show them a custom thank-you message. The question names in the conditions are wrapped in curly braces because they reference the internal IDs of your NPS questions, not the user-facing labels.

Building a Rule: Conditions

Clicking Add New (or the pencil icon on an existing rule) opens the rule editor, which has two sections: Define condition(s) at the top and Define action(s) below it.

Build mode and Edit mode

The condition editor offers two modes, selected by the Build and Edit tabs at the top of the section:

  • Build is the default. It provides a structured form with dropdowns for selecting a question, an operator, and a value. This is the right mode for most users and most conditions.
  • Edit switches to a raw text input where you can type conditions directly as expressions, for example {nps_score} = 5. This is a power-user mode for conditions the Build interface cannot express cleanly.

Selecting a question

The first dropdown lets you choose which question's answer the condition evaluates. The default NPS exposes three questions: Email, nps_score (the 0-to-10 rating), and the follow-up question (which carries whatever internal ID your NPS uses, often based on the question's name). If your NPS has custom questions added beyond the defaults, those will also appear in the dropdown.

Choosing an operator

The middle dropdown stays grayed out until you select a question. Once a question is selected, ten operators become available:

  • Equals and not equals for exact-match comparisons.
  • Greater, less, greater or equals, and less or equals for numeric range comparisons (most useful with nps_score).
  • Contains and not contains for substring matches in text fields.
  • Is empty and is not empty for checking whether a question has been answered at all, regardless of value.

Entering a value

The third field, where you supply the value to compare against, adapts to the question you selected. For Email and free-text questions, it displays as a text input. For nps_score, it displays as the 0-to-10 rating buttons, letting you click the exact score the condition should evaluate against. The empty and not-empty operators do not require a value because the comparison is against existence, not against a specific answer.

Combining multiple conditions

Clicking Add condition adds a second condition row below the first. The second row (and any additional rows) begins with an AND/OR selector, so you can build compound logic. For example, a rule fires when nps_score > 8 AND email contains @example.com, or when nps_score < 3 OR passive_experience contains the word “broken.” Each new condition row has the same question, operator, and value fields as the first.

Use the red X next to any condition row to remove that condition without affecting the others.

Building a Rule: Actions

Below the conditions, the Define action(s) section controls what happens when the condition (or combination of conditions) is met. Click the Select an action to add dropdown to see the available actions. A single rule can include multiple actions by clicking Add new action to stack them.

Available actions

The dropdown offers nine action types:

  • Question visibility shows or hides a specific question. Useful for revealing follow-up questions only to respondents whose prior answers make them relevant.
  • Question enable/disable allows or prevents interaction with a question without hiding it. The question remains visible but cannot be answered.
  • Question optional required toggles whether a question is optional or required based on the condition. Useful for making a follow-up question mandatory for specific score ranges and optional for others.
  • Complete survey ends the response immediately when the condition is met. Useful for disqualification flows or for ending the survey early for specific respondents.
  • Set question value programmatically assigns a value to a specified question. The value populates without the respondent seeing or interacting with the question.
  • Copy question value copies a value from one question into another. Useful for carrying an answer forward into a dependent question.
  • Skip to question jumps the respondent past intervening questions to a specific target. Useful for branching flows where some respondents should skip sections that do not apply to them.
  • Run custom expression is an advanced option inherited from the survey platform Oomiji uses to power its conversation builder. It allows logic conditions based on expression syntax defined by that platform. Because this option operates outside Oomiji's own configuration layer, documentation for supported expressions and syntax is maintained by the underlying tool. If you need to use custom expressions, refer to the SurveyJS expression documentation for guidance.
  • Custom Thank You page text displays a custom message on the thank-you page shown after the respondent submits. Selecting this action opens an inline rich-text editor where you can type your message directly or paste HTML. Basic formatting (bold, italic, underline, subscript, superscript, bullets, quotes) is supported. Different rules can produce different thank-you messages, which is how you give Promoters and Detractors distinct post-submission experiences.


Stacking multiple actions on one rule

Clicking Add new action adds a second action to the same rule. All actions on a rule fire when the rule's condition is met. This lets you chain effects, for example: when nps_score > 8, show a custom thank-you message AND set a question value AND skip to a specific question. Use the red X next to any action to remove it without affecting the others.

Saving and Managing Rules

At the bottom of the rule editor, three buttons control how you exit:

  • Save and return commits the rule and closes the editor, returning you to the NPS Logic tab where the new rule appears in the table.
  • Save commits the rule but keeps you in the editor, so you can continue making changes.
  • Return without saving discards any changes you have made in the editor and returns you to the NPS Logic tab.

To edit an existing rule, click the pencil icon on its row in the rules table. The rule editor opens with the rule's current conditions and actions loaded. To delete a rule, click the red X on its row.

Deletions are immediate and cannot be undone through the editor, so confirm before clicking.

Worked Examples

The following three patterns cover the most common use cases for NPS Logic.

Example 1: Score-branched thank-you messages

The most common use of NPS Logic is showing different thank-you messages to Promoters, Passives, and Detractors. This lets you thank your loyal customers warmly, acknowledge complaints from unhappy customers, and extend a targeted nudge to your Passives, all within the same NPS conversation. Build three separate rules, one per category:

Rule A (Promoters):

  1. Condition: nps_score greater or equals 9
  2. Action: Custom Thank You page text with a message like “Thank you for your support. If you would be open to sharing your feedback publicly, we would love to hear more.”

Rule B (Detractors):

  1. Condition: nps_score less than 7
  2. Action: Custom Thank You page text with a message like “Thank you for the honest feedback. A member of our team will be in touch within the next few days.”

Rule C (Passives):

  1. Condition: nps_score equals 7 OR nps_score equals 8
  2. Action: Custom Thank You page text with a message like “Thank you for taking the time. If there is something specific that would move you from a 7 to a 10, we would be grateful to hear it.”

Each rule fires only when its score condition is met, so each respondent sees exactly one thank-you message based on their rating. A Promoter does not see the Detractor apology; a Detractor does not see the Promoter reinforcement.

Example 2: Conditional follow-up question for a specific score range

Suppose you have added a custom follow-up question to your NPS that asks Passives what specifically could move them to a higher score. You want this question to appear only to Passives, because asking Promoters or Detractors would produce noise in your response data. Build a rule that uses Question visibility:

Rule:

  • Condition: nps_score equals 7 OR nps_score equals 8
  • Action: Question visibility → Show your custom Passive-targeted follow-up question

Promoters and Detractors will not see this question; only Passives will. This keeps your follow-up data clean and focused on the respondents most likely to benefit from targeted attention.

Example 3: Disqualifying responses that do not meet criteria

If you share your NPS via the public URL and want to prevent certain respondents from completing a full response, use Complete survey as the action. This ends the response early when a condition is met. A common use case is filtering out internal or test email addresses:

Rule:

  • Condition: email contains @yourcompany.com
  • Action: Complete survey

A respondent with an internal email address will be marked complete without their response feeding the dashboard, which keeps your NPS data focused on real external customers. You can pair this with a Custom Thank You page text action that explains why the response was ended, if you want to handle the disqualification gracefully.

What's Next

Once your logic rules are in place, the rest of the Satisfaction workflow follows: