Troubleshooting ServiceNow Vendor Risk Management: A Practical Guide

This guide helps a VRM administrator or risk analyst work out why a vendor risk process is failing. It sets out symptoms such as questionnaires not sending, responses not appearing, scores that look wrong, escalations that never fire and duplicate vendor records, and where to look first for each. It says to narrow the search before changing configuration.

Symptom: Vendor Assessment Questionnaires Are Not Sending

If vendors are not receiving questionnaires, check the vendor outreach configuration. Verify that vendors have email addresses in their records. Check that the questionnaire workflow is active and published. Look at the workflow run history to see if the workflow executed and what the results were. If workflows ran but no emails were sent, check the notification configuration. Verify that notification emails are not being suppressed by email filters or batched for later delivery. If your organization uses MID Server for email, verify the MID Server is healthy and connected. Test by manually triggering a questionnaire send to a single vendor to isolate the issue. If the problem is intermittent, check whether ServiceNow job queues are backed up or running slowly.

Symptom: Vendors Complete Questionnaires But Responses Do Not Appear

If vendor responses are submitted but not appearing in ServiceNow, check the integration between the questionnaire portal and VRM. Verify that the webhook or API that receives responses is working and returning a success status. Check the integration logs for errors. If the integration is configured to validate responses before accepting them, check the validation logic. If responses are being rejected, look at validation error details. For example, if a required field is missing, the integration logs should say which field. Contact the vendor to resubmit complete information. If responses are being lost, check whether responses are being queued somewhere. The questionnaire system may batch responses before sending them to ServiceNow; confirm the batch send succeeded. If no responses are appearing at all, verify that integration credentials are still valid and not expired.

Symptom: Risk Score Is Not Calculating or Is Incorrect

If vendor risk scores are not calculating, check the risk scoring model. Verify that the scoring algorithm is enabled and configured correctly. Risk scoring in VRM often uses vendor responses, historical performance and incident history. If the score is blank, check whether all required data is populated. If a vendor has no incident history, for example, the scoring algorithm may not have enough data to calculate a score. If the score is incorrect (lower or higher than expected), review the scoring logic. For example, if a vendor that should be high-risk is showing low-risk, check whether the scoring weights prioritize the right risk factors. Test the scoring model manually: look at a specific vendor’s data and walk through the scoring algorithm to verify it is calculating correctly.

Symptom: Vendors Are Not Escalating Automatically

If high-risk vendors are not escalating to management for review, check the escalation workflow. Verify the escalation condition: at what risk score or number of findings does a vendor escalate? Test the condition with sample data. If the condition is not met, the escalation will not trigger. Verify the escalation target: to whom should escalations go? Check that the escalation recipient’s user record exists and they have the right permissions. If escalations are going to a role or group, verify the group is populated with the right members. Check the escalation notification: verify the recipient receives the escalation email. If emails are not being received, check email configuration and filters.

Symptom: Duplicate Vendor Records

If the same vendor appears multiple times in VRM, data consolidation is needed. Check for vendors with similar names or multiple entries for the same organization. Use the vendor de-duplication workflow if available. If not, manually merge records: select the primary record, verify all important data is captured, and merge duplicate records into the primary. After merging, confirm that assessments, contracts and risk scores roll up correctly to the consolidated record. Implement name normalization to prevent duplicates going forward: standardize how vendor names are entered so duplicates are caught before records are created.

Symptom: Vendor Data Is Out of Date

If vendor information (contacts, business details, security certifications) is stale, check the data refresh frequency. Vendor data comes from two sources: manual updates by vendor administrators and periodic vendor self-assessment. If manual updates are not happening, establish a process where vendor owners update their records at least annually. If assessments are not periodic, configure automatic reminders to vendors asking them to update information. Check the last modified date on vendor records to identify which vendors have not updated in a long time. Send those vendors an update request.

Symptom: Integration with Procurement Is Broken

If VRM is not syncing with procurement or contract management systems, check the integration. Verify that the integration credentials are still valid and have the required scope. Check the integration job logs for errors. If the integration timed out, check whether the external system was unavailable or slow. If the integration is one-way, check the sync direction. If procurement creates new vendors and ServiceNow should receive them, the integration should be bidirectional. Test the integration manually: create a vendor in VRM and verify it appears in procurement within the expected timeframe. If syncing is failing in one direction but not the other, investigate the failing direction specifically.

Symptom: Compliance Requirements Are Not Being Tracked

If vendors are not responding to compliance requirements (certifications, audit requirements, compliance attestations), check the compliance requirement configuration. Verify that requirements are linked to vendors. Check whether vendors have been notified of requirements. If they have not been notified, send notifications manually. If vendors have been notified but not responding, escalate to procurement and relationship managers to follow up. Track compliance status in a dashboard so leadership can see which vendors are compliant and which are not.

Work the triage order before changing any configuration

Most vendor risk faults are reported as a symptom on one record, and the fastest route to a fix is to narrow the search before opening the configuration. Follow the same order each time. It keeps a single misdiagnosis from turning into a sequence of unrelated changes that nobody can later unpick.

1. Confirm which record the problem appears on, and whether the same problem shows on other vendors of the same type.
2. Check who can see the record. Access rules and group membership come before data questions.
3. Check timing. Scheduled jobs, approval waits and reminder intervals explain many “nothing happened” reports.
4. Check for a recent change to a template, flow, scoring rule or integration mapping, and note its date.
5. Reproduce the fault with one test vendor that you create for the purpose and delete afterwards.
6. Only then edit configuration, one change at a time, so any regression can be traced.

Access problems that look like data problems

A reviewer who reports that a vendor assessment is missing often cannot see it at all. Access rules on the assessment and issue tables can hide records by group or by company, and the reviewer sees an empty list rather than an error message. Before raising an incident, ask the reporter to open the same record from a second account with the same role. If the record appears there, the problem is access, and the data is fine.

Symptom and first place to look

Writing an incident note that gets a fix in one pass

The note that gets a problem resolved quickly names the vendor record, the time the fault was seen, the user who saw it, the expected result and the observed result. Screenshots help, but the record identifier matters more. Without it, an engineer rebuilds the scenario from memory and the reproduction takes longer than the fix. Ask the reporter to say what they did immediately before the fault, because the preceding action is usually the clue.

When to stop troubleshooting and escalate

If a fault affects more than one vendor, touches a payment or a regulatory deadline, or appears straight after a platform upgrade, stop experimenting and escalate with the evidence gathered so far. The note on automation exception handling covers containment, explanation and recovery when an automated action fails, which applies when a reminder or escalation never fires. A fix applied under pressure to a single scoring rule often moves scores for vendors nobody intended to affect, and those side effects can be harder to explain than the original fault.

Why does a vendor appear in the register but not in the assessment queue?

Usually the record lacks the field that the assessment trigger checks, or the trigger requires a value that the procurement form does not populate. Compare the vendor record directly against the trigger condition before assuming the workflow itself has broken.

Can we reverse a bulk update to vendor records?

Only when the update was logged with previous values, or was run from an import that can be replayed. Export the affected fields before any bulk change, so a reversal has a known baseline even if the platform history is incomplete.

Does a failed integration explain stale vendor data?

It can, but a stale field is often a field that nothing ever updates. Compare the time of the last successful sync with the time of the last human edit before blaming the connector. The integration patterns guide covers the systems that vendor risk data is usually drawn from, such as procurement and external risk services.

Which access checks should run after a platform change?

Repeat the two-account test on one vendor of each risk tier, and re-run the access recertification for anyone whose group membership changed, and confirm that a user outside the vendor owning group cannot read the assessment. Access regressions are quiet, and they tend to surface only when a reviewer finally needs the record.

A growing fault list is a signal to review the configuration more widely.

ServiceNow vendor risk management troubleshooting: table names and where each log lives

When a vendor risk process fails silently in ServiceNow, the evidence usually sits in four places: the vendor record in the company table, the email log, the scheduled job list and the flow execution history. Check those before editing any template or scoring rule.

The names below are common out-of-box values. Check them on your own instance and release, because labels, menus and defaults change between releases and between vendor risk versions. Teams in regulated sectors can see a worked scope in ServiceNow vendor risk management for insurance.

Example (hypothetical): a reviewer reports that reminders went out twice for one vendor. The administrator searches the email log for that vendor contact and finds two messages created by different scheduled jobs on different days. The scheduled job list shows a copied job, left active after a test. Disabling the copy ends the repeat, and no change to the questionnaire template was needed.

Where can I confirm a notification was generated?

Open the email log and search by recipient and time. A row that shows the message as sent means the platform handed it to the mail server. A message still waiting to send, or no row at all, points at notification rules or mail configuration rather than at the questionnaire itself.

How do I see where a flow stopped?

Open the flow execution history, find the run by record or time, and expand its steps. The first step with an error or a skipped condition marks where to look. If there is no run at all, the trigger condition may not have matched the record, or the flow may be inactive.

Is a duplicate vendor a data fault or a process fault?

Treat it as both. Merge the records to repair the data, then find which intake route created the second company record, such as a manual entry or an integration with no matching rule. Without that second step the duplicate returns. Related guidance is in ServiceNow Vendor Risk Management guides and services.