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:
- Click Satisfaction in your toolbar.
- 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):
- Condition: nps_score greater or equals 9
- 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):
- Condition: nps_score less than 7
- 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):
- Condition: nps_score equals 7 OR nps_score equals 8
- 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:
- Building and Configuring an NPS Conversation covers the rest of the builder including the NPS Designer tab, the Properties panel, and the default questions.
- Sharing and Distributing NPS Conversations covers the two distribution paths once your NPS is configured.
- Segmenting and Acting on NPS Responses shows how to act on the data your NPS collects once responses start coming in.