Unable to trigger legacy Risk Assessment (assessment_master) on Service Portal for Record Producer

prudhvipotr
Giga Contributor

yesterday

Hi ServiceNow Community,

I am trying to trigger a Risk Assessment when a user submits a Change Request via a Record Producer in Employee Center  (/esc). The goal is to present the Risk Assessment to the user upon record creation so they can complete it and automatically update the Risk field on the Change Request.

However, I am running into roadblocks due to a mix of legacy assessment tables and Service Portal framework limitations.

Environment Details:

  • Portal: Employee Center (/esc)

  • Source: Record Producer (creates change_request)

  • Assessment Table: assessment_master (Sys ID: XXXXXXXXXXXXaabcf9b9af96194b, 

  • Condition Table: assessment_conditions

  • Target Table: change_request

What We Tried & Where It Failed:

1. Record Producer Script (producer.portal_redirect)

  • Attempt: Used producer.portal_redirect in the Record Producer script calling CreateAssessment() / AssessmentUtils().createAssessments().

  • Failures Encountered:

    • invalidtype error: createAssessments() returned [invalidtype].

    • "You are not authorized or the record is not valid": Opening /esc?id=take_survey&instance_id=... gave authorization errors on the widget.

    • Default Redirection Override: Service Portal automatically overrode producer.portal_redirect and landed users on the default form view: /esc?id=form&table=change_request&sys_id=....

4. Server-Side Business Rule (after insert)

  • Attempt: Moved the creation logic to an after insert Business Rule on change_request to keep client scripts clean.

  • Failures Encountered:


    • 0 Questions / Blank Survey Page: When attempting to create asmt_assessment_instance records manually, the take_survey widget loads a completely blank page with 0 questions because the definition resides in assessment_master (Legacy Survey Engine) rather than asmt_metric_type.

Code snippet currently in the Business Rule:

JavaScript
(function executeRule(current, previous) { var changeSysId = current.getUniqueValue().toString(); var assessmentMasterSysId = "XXXXXXXXXXXXX0aabcf9b9af96194b"; var currentUser = current.opened_by.nil() ? gs.getUserID() : current.opened_by.toString(); // 1. Create task_assessment var grTA = new GlideRecord("task_assessment"); grTA.addQuery("task", changeSysId); grTA.addQuery("assessment", assessmentMasterSysId); grTA.query(); var taskAsmtId = ""; if (grTA.next()) { taskAsmtId = grTA.getUniqueValue(); } else { grTA.initialize(); grTA.task = changeSysId; grTA.assessment = assessmentMasterSysId; taskAsmtId = grTA.insert(); } // 2. Generate legacy survey instance / questions // [Looking for the correct API or approach here] })(current, previous);
 

Questions for the Community:

  1. What is the supported, best-practice method to trigger a legacy assessment_master survey from the Service Portal ?

  2. Which specific API or table structure (survey_instance / survey_response vs. asmt_assessment_instance) should be instantiated for assessment_master records so that the portal take_survey widget renders questions correctly instead of a blank page?

  3. How can we ensure the user is seamlessly directed to the survey upon Record Producer submission without getting blocked by authorization errors or default portal page overrides?

Any guidance, code snippets, or architectural recommendations would be greatly appreciated!

0 Helpfuls
  • 36 Views
3 REPLIES 3

Suryansh Verma
Mega Sage

an hour ago

@prudhvipotr 

 

The issue is caused by using an assessment_master sys_id with the current SNC.AssessmentCreation API and the Employee Center take_survey page. assessment_master belongs to the legacy survey engine, while createAssessments() expects a current Metric Type or Survey Definition. This is why it returns invalidtype.

Manually inserting an asmt_assessment_instance does not create the corresponding assessment questions and results, so the take_survey widget displays a blank questionnaire.

For Change Management, the recommended solution is to migrate the legacy assessment through Change → Risk Assessment (legacy) → Migrate to Risk Assessment, using the current Change Management – Risk Assessment application. Configure the migrated conditions, questions and thresholds, and use the current risk-assessment lifecycle.

For Employee Center, redirect the Record Producer to a custom landing page using producer.portal_redirect. That page should expose the current Change Risk Assessment action. Do not manually create records in the legacy or current assessment tables.

When a generic portal questionnaire is required instead, rebuild it as an active and published asmt_metric_type, generate the instance through SNC.AssessmentCreation().createAssessments(), and pass the returned instance sys_id to the take_survey page. Custom logic would then be required to update the Change risk field from the completed assessment.

 

If it is helpful, please mark it as helpful and accept the correct solution by referring to this solution in the future, it will be helpful to them.

0 Helpfuls

VJ_Srivastava
Tera Contributor

16m ago

Hello Prudhvipotr,

From an architectural standpoint, the roadblocks you are hitting are the direct result of combining a deprecated, legacy backend framework (assessment_master) with the platform's most modern presentation layer (Employee Center).

ServiceNow intentionally decoupled the modern Service Portal from the legacy survey engine years ago. The take_survey widget expects the normalized data model of the modern Assessment engine. Attempting to force compatibility by hacking Record Producer redirect scripts or writing heavy after insert Business Rules to instantiate deprecated survey tables introduces severe technical debt.

As an architect, it is critical to recognize when a requirement is pushing you toward an anti-pattern. If you continue down this path, you will have to build a heavily customized Service Portal widget just to read the legacy assessment_master tables, which completely breaks your upgrade path and adds a permanent maintenance burden on your development team.

The correct architectural decision here is to pause the portal configuration and execute a data migration. Rebuild the risk assessment definitions in the modern Risk Assessment engine. Doing so natively unlocks the out-of-the-box integration with Change Management risk calculators, fully supports the Employee Center framework, and aligns your platform with ServiceNow's future roadmap.

0 Helpfuls

Tanushri
Giga Contributor

12m ago

Hi @prudhvipotr ,

This is a notorious friction point when organizations try to bridge legacy backend processes with the modern Service Portal framework. The root cause of the "0 Questions / Blank Survey Page" and the authorization errors boils down to a fundamental schema incompatibility.

The out-of-the-box Employee Center take_survey widget is hardcoded to query the modern Assessment engine tables (specifically asmt_assessment_instance, asmt_metric_type, and asmt_metric). It simply does not know how to read or render the legacy assessment_master or survey_question tables.

Here is the technical breakdown of your options:

  1. The "Band-Aid" Fix (Not Recommended): If you absolutely cannot migrate off the legacy engine today, you cannot use the take_survey widget. Instead, you would need to redirect the user to the classic UI page wrapper. In your Record Producer script, you would construct a redirect URL pointing to the old processor, such as: producer.portal_redirect = "?id=form&table=assessment_master... " or use an iframe widget to render assessment_take2.do. This often results in a poor, non-responsive UI experience on the portal.

  2. The Platform-Native Fix (Highly Recommended): The CreateAssessment() API failures and widget blank pages are the platform's way of telling you these technologies are decoupled. You need to migrate your Risk Assessment from the legacy assessment_master framework to the modern Assessment Metrics (asmt_metric_type) framework.

    • Once you recreate the questions in the modern engine, the system will natively generate the asmt_assessment_instance records.

    • The take_survey widget will instantly recognize the instance, render the questions beautifully without authorization errors, and you can simply use the native OOB UI Actions or standard Record Producer redirects to pass the sys_id into the portal URL (e.g., /esc?id=take_survey&instance_id=YOUR_NEW_INSTANCE_SYS_ID).

Stop fighting the Service Portal framework with Business Rules meant for a deprecated engine—migrating the data to the new schema is the only sustainable technical path forward!

0 Helpfuls