Can variables in Playbook "Questionnaire" activities be dependent on previous responses?

[Daniel_san]

Hi everyone,

I'm working on a Playbook that includes a "Questionnaire" activity with multiple questions.

I'd like to replicate the behavior available in Catalog Item forms, where it's possible to show or hide questions based on previous answers — for example, conditionally displaying a field based on a prior true/false (checkbox) selection.

Is this kind of conditional logic supported in Playbook Questionnaire activities?

If not, are there any recommended workarounds to achieve similar behavior?

Note: The only workaround I’ve found so far is to split the questions into separate activities within the Playbook and apply conditions between them. However, this approach is cumbersome to configure and maintain, and it's not very user-friendly for agents either.

Thanks in advance for any guidance!

[Maik Skoddow]

Hi @Daniel_san 

Direct, in-form conditional logic for showing/hiding questions within a single Playbook Questionnaire activity is not currently supported in ServiceNow. The most common workaround is to split questions into separate activities and use conditional branching, but this is not ideal for complex or agent-facing flows as you already have figured out. For more advanced needs, custom UI development or leveraging Catalog Items/Surveys may be necessary, depending on your process requirements.

Maik

[MHU]

As of right now (Zurich release), this still seems to be the case, conditional logic within a single Playbook Questionnaire activity isn’t supported.
I completely agree that this would be a great improvement for more dynamic Playbooks. Hopefully, we’ll see something like this added in a future release!

[Daniel_san · Accepted solution]

URL to the idea I submitted to the vendor: Idea - Support conditional logic and visibility in Playbook Questionnaire questions. Please consider giving it an upvote if you think this functionality would be useful 

---

In the meantime, I wanted to share a WORKAROUND that I found which seems quite clean and works well:

1. Create a custom table containing the questions needed for the dynamic questionnaires.
   1. Note: the custom table must be associated with a subscription you already have.
   2. Recommended to include a couple of fields that allow to clearly link the records to the corresponding playbooks or activities: in my case, I created reference fields for RITM and TASK, and an additional string field called CONTEXT (to identify the trigger Playbook).
2. In the Playbook where you want to use the dynamic questionnaires, create a record in this custom table (I do it by using a "Create record" action in a subflow).
3. When the agent must answer the questions in the Playbook, instead of using a Questionnaire activity, use a Record form activity pointing to the custom table and displaying the needed fields/questions.
   1. Define the necessary UI Policies so questions are shown or hidden based on previous answers (similar to how it works with catalog item variables).
   2. If needed (for example, if the table will support multiple questionnaires), you can create different Views to be used in the Record form activities and/or the UI Policies.

BONUS: if the architecture/design of the solution is well thought out, it’s possible to take advantage of storing the responses in a table instead of in Playbook-type activities: for example, for later reporting, to pre-fill the responses with anything we need (this can also be done more or less with questionnaire activity variables, but it’s not as straightforward in Playbooks), to use client scripts, and so on.

---

IMPORTANT: I’ve tested this workaround, and it works perfectly. That said, use it with caution... consider your number of questions/questionnaires involved, the potential impact on performance or scalability in your own instance, and any other implications I may have overlooked. Hopefully, this functionality will eventually be added natively to the questionnaire module by ServiceNow.

I would greatly appreciate any comments, advice, or constructive criticism to consider regarding this approach.

[JulianP32954866]

Depends on what you are after.  I have typically done this with reference fields where I need to restrict what the questionnaire shows from my source record, from a previous questionnaire value, or you can try to see if it is in any other sys_flow_data entry or push come to shove, write back to the parent record somewhere.

You can create a database view that will let you link from your source record to all the sys_variable_value and sys_flow_data_var. 

This is your link to the parent and all other questionnaires.

That way, when your next questionnaire loads, you can make it read whatever you are after and drive the response via a script include

This is just populating with some initial change records, but for a customer this goes off and reads a list of relationships for them to modify

The Flow Data Variable - advanced view.  This is a list

And then the Dynamic filter is