Seeking Best Approach: Complex Verification Process with 50+ Dynamic Questions in ServiceNow
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-15-2025 06:13 PM
Hey everyone,
I'm tackling a complex verification process in ServiceNow and need advice on the best architectural approach. We have u_verification_process records (extending task) that require users to complete a 50+ question dynamic questionnaire.
Key Requirements:
Two-step entry: Record created by one user/integration, then completed by another.
Dynamic UI: Questions appear/disappear based on previous answers.
Granular "Observation" field: Each question must have its own specific "Observation" text field that appears if the answer is "Not Applicable." This is crucial.
Partial completion: Users need to save progress and return later, given the number of questions.
Calculations & Workflow: Assign weights to answers for a total score, possibly triggering workflow actions.
UI: Flexible. Depends on the solution. Might be UI16, Service Portal or Worspace.
Approaches Considered:
Native Variables (Service Catalog Variables/Sets):
Pros: Native, integrates well with workflows, supports dynamic UI via UI Policies, allows partial saving.
Challenge: The need for a unique "Observation" field per question means creating 50+ question variables PLUS 50+ distinct "Observation" variables, doubling the variable count and UI Policies. This feels cumbersome for management and future scaling. Also, variables don't appear automatically if the record isn't created via a Record Producer, so I would need a workaround. Maybe creating the records directly on "questions_answered" table via script or flow, but then the variables created like this can't be collapsed in the form, even if they are inside a variable set.
Dedicated Question/Answer Tables with Custom UI (UI Builder for Workspace or widget for Service Portal):
Data Model: Separate tables for u_question (master questions) and u_answer (stores u_process_id, u_question_id, u_answer_value, and the specific u_observation_text).
Pros: Perfect data model for granular observations, UI flexibility (e.g., true tabs), scalable question management.
Challenge: High development effort. Requires custom coding for all dynamic UI logic, data persistence, and replacing native UI Policy/workflow integrations. Losing "out-of-the-box" benefits is a big trade-off.
ServiceNow Survey Module:
Pros: Built for questions/answers.
Challenge: Designed for feedback/assessments, not ideal for "living" process records or deep workflow integration, and UX for gradual task completion is clunky. Not a good fit for this "process verification" nature. There are also some limitations, like the impossibility to set a default value on client for "Observation" questions (which is a requirement).
Has anyone solved this "granular observation per question" challenge effectively in ServiceNow? Any clever tricks or hybrid solutions with less custom development than the options I considered?
Thanks for your expertise!
- Labels:
-
Architect
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-15-2025 06:26 PM
If it were me, I would choose option 1. Variables can be displayed on the record producer—you just need to copy a formatter and modify it. As for the 50+ observations, it's mostly repetitive work with a higher volume.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-15-2025 06:44 PM
There's also the fact that reporting would be much harder this way. Also, the observation variables wouldn't be directly tied to their respective question. I guess I could reference it in the name or something, but it still feels a bit cumbersome to me. Also, in the event that the record is not created by the record producer, the default formatter isn't ideal since it doesn't segragate by variable sets for some reason. Maybe there's a table I couldn't find storing that information, but in my experience variables are only visually segregated by their respective variable set on the variable editor if the record is created through the record producer.
Another option I just thought of was creating three tables:
1 - Main process
2 - Questions table with respective categories
3 - Relationship table between main process and questions, with a choice column and the observation column.
Then, inside the main process record I create multiple related lists, all from the same table but filtered by question category. That way, the user would fill out the questions by directly interacting with the related lists, using cell edit. Still far from ideal because the questions are fairly long and the related list layout is not ideal for this.
Another option is going with a record producer form mapping every question and obervation to variables, but on the producer script those variables would create the records on the relationship table. If the user only wants to submit 10 questions out of the 50 at the present time, they could submit and only that portion would be filled on the table. Later, we could use GlideAjax to automatically fill out the variables if the records from those 10 questions already exist, simulating a persistent form.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-15-2025 07:01 PM
I prefer option 2 record producer