Troubleshooting ServiceNow Strategic Portfolio Management: A Practical Guide
This guide helps a portfolio administrator work out why Strategic Portfolio Management is producing an unexpected result, starting from the symptom a user describes. It covers unexpected rankings, resource over-commitment, slow recalculation, stalled approvals and mismatched report totals, and the order in which to check data, logic and timing.
Symptom: Portfolio Prioritization Produces Unexpected or Illogical Rankings
If portfolio prioritization is ranking projects in unexpected order, first verify the prioritization model. Check that weighting factors (value, strategic alignment, risk, cost) reflect business priorities. If value weighting is 1 and risk weighting is 10, high-value-high-risk projects will be deprioritized; is that intentional? Check score calculations: if projects have different scoring scales (one project scores 0-100, another 0-10), normalization may be needed before comparison. Run prioritization with test data: create known projects with specific scores and verify ranking matches expectations. If actual project rankings are surprising but test rankings are correct, the issue is likely data quality: project scores may not reflect reality. Check that project scoring is done by knowledgeable people and validated before portfolio calculation.
Symptom: Resource Allocation Is Over-Committing or Under-Utilising Capacity
If resource plans show people assigned to more hours than they have available, or conversely showing idle time when work should be allocated, check the resource capacity calculation. Verify that capacity is defined correctly: what is the standard working week for a full-time person in your organization? Are vacation days and holidays subtracted from available capacity? Are training days accounted for? Check that resource assignments are being counted correctly: if a person is assigned to multiple projects, are the hours being summed correctly, or is the system showing only the largest assignment? Look at resource allocation aggregation: does the system show how much capacity is allocated across all projects per resource? Test by creating a simple scenario: allocate a resource to two 20-hour projects; the system should show 40 hours allocated if the resource has 40 hours available. If the result is wrong, there is a calculation error.
Symptom: Portfolio Recalculation Is Very Slow or Times Out
If portfolio calculation is taking many minutes or timing out, performance optimization is needed. Check the number of projects in the portfolio: large portfolios (hundreds of projects) can take longer to calculate. Check the complexity of the prioritization algorithm: if the algorithm checks many conditions or performs nested calculations, that adds time. Identify the slowest part of the calculation: is it data retrieval (reading project records), calculation (computing scores), or sorting (ranking)? Use the diagnostics available on your instance, such as the performance and transaction logs, to see which lookups are slow and whether the fields they filter on are indexed. Add indexes on frequently-queried fields. Consider breaking large portfolios into sub-portfolios: instead of optimizing one portfolio of 500 projects, create five portfolios of 100 projects and prioritize between portfolios separately. Test performance with production-scale data before go-live.
Symptom: Resource Conflicts Are Not Being Flagged or Resolved
If two projects need the same resource at the same time but the system does not alert, check the conflict detection configuration. Verify that the system is configured to check for double-booking. If conflicts are detected but not resolved (the system finds them but leaves people double-booked), check the resolution workflow. Who should decide resource allocation when there is a conflict: the project managers, the resource manager, or the portfolio manager? Is there an approval workflow for conflict resolution? Test by creating a deliberate conflict: assign one resource to overlapping time periods in two projects; the system should flag or prevent the conflict based on configuration.
Symptom: Portfolio Changes Are Not Flowing to Dependent Systems
If portfolio decisions (funding, resource allocation, priority) are not reaching finance, project management, or resource management systems, check the integration. Verify that integrations are enabled and configured. Check integration logs for errors: are messages being sent but failing to deliver, or are they not being sent at all? If messages are failing, what is the error? Authentication timeout, data validation failure, or destination system unavailable? Test the integration manually: change a portfolio decision in Strategic Portfolio Management and check if the change appears in the connected system within the expected timeframe. If not, manually push the update through the integration and verify it reaches the destination.
Symptom: Approval Workflows for Portfolio Changes Are Stuck or Escalating Incorrectly
If portfolio change approvals are not routing to the right people, or approvers are not taking action within expected timeframes, check the approval workflow configuration. Verify that approval rules route to the correct people based on project value, risk, or other criteria. If a high-value project needs executive approval but low-value projects need manager approval, are those rules configured correctly? Test the workflow with sample portfolio changes at different levels. Check escalation rules: if an approval has been pending longer than the escalation period set in the rule, does it escalate to a higher authority? Test that escalation triggers correctly. If approvals are routing to the right people but they are not taking action, that is a change management issue, not a configuration issue; senior leadership may need to emphasize approval accountability.
Symptom: Portfolio Reports Show Incorrect Totals or Missing Data
If portfolio dashboards and reports show incomplete or incorrect financial or resource summaries, check the report data source. Verify that reports are pulling from the correct table and using correct aggregation logic (sum, average, count). Check for data quality issues: projects with missing cost, schedule, or resource data will show incomplete totals. Run a data quality audit to identify records that are missing required fields. Recalculate portfolio reports after fixing data quality issues. For ongoing accuracy, configure data validation rules that prevent incomplete project records from entering portfolio calculations.
Symptom: Portfolio Cannot Recalculate After Major Portfolio Changes
If portfolio calculation fails after a major change (adding many projects, changing the prioritization model, adding new constraints), check for data issues first. Are all projects fully configured with required data (cost, resource needs, timeline)? Are there circular dependencies (Project A requires outcome of Project B, which requires outcome of Project A)? Are there contradictory constraints (cannot have enough resources to fund all projects and meet timeline)? If data is correct but calculation fails, the algorithm may not handle edge cases well. Work with implementation team to handle the edge case, or adjust portfolio scope to avoid the issue.
Start with the symptom a user can describe, not the module
Portfolio problems reach the administrator in the user’s words: “my project moved and I did not change it”, “the total on the dashboard does not match the list”, “the sponsor never got the email”. Each of those points to a different layer, so the first job is to translate the complaint into the one observable fact that separates the causes. Ask what the user saw, which record and view they were in, when it happened, and what they expected instead. Those four answers usually narrow the search to one of the causes in the table below before anyone opens a configuration screen.
Matching the symptom to the likely cause
| What the user reports | Usual cause | First check | Evidence to capture |
|---|---|---|---|
| A score looks out of date after an edit | The calculation runs on a schedule or on a separate trigger, not on save | When the last calculation ran, compared with the edit time | The calculation timestamp and the change history on the scored fields |
| The list and the form show different values | The list uses a different field, a rounded value or a filter that hides some records | Which field each view reads, and the active filters on the list | A screenshot of both views with the record number visible |
| Duplicate project records after an import | The import has no stable matching key, so each run creates new rows | Whether the import matches on a unique reference or on the name | The import log and the two record numbers that should have been one |
| A scheduled portfolio job silently did nothing | The job’s run-as user is inactive or lacks rights, or the schedule uses the wrong time zone | The job’s last run result and the run-as account | The job history and the account’s role list on the day it failed |
| A sponsor did not receive a notification | The notification condition was not met, or the sponsor has no email address on their user record | The notification’s condition, tested against that record | The sponsor’s user record and the notification log for the record |
| Budget totals differ from finance | Mixed currencies converted at a different rate or date, or rounding applied at a different step | The currency of each project and the rate date used | A short list of the projects behind the difference, with their currency |
The duplicate-record row is one that is often misdiagnosed. Teams blame the platform and then try to merge the rows by hand, which removes the symptom while leaving the import free to repeat it on the next run. Fix the matching key first, then clean the existing duplicates. Setup choices that produce this kind of problem are listed among the common mistakes in portfolio builds.
A triage order that avoids changing things twice
- Reproduce the symptom on a single named record and write down the exact steps, so the same steps can be repeated after a fix.
- Check the data before the logic. Confirm the record has every field the calculation or the rule needs, because a missing value often looks like a fault in the code.
- Check timing next. Find when the value was last calculated, when the record last changed, and when the job last ran, and compare the three.
- Check the identity the process runs under, since a job or rule that works for an administrator can fail for the user who actually triggers it. A failure that leaves no visible trace is the hardest kind to find, and the automation exception handling approach shows how to make those failures visible.
- Change one thing, test again on the same record, and only then move on. Changing several settings together makes it impossible to say which one fixed the problem.
- Record the cause and the fix against the symptom so the next person who reports it starts from the answer.
What to gather before escalating to a specialist
- The record number, the view or form used, and the time of the event, with the time zone stated.
- The steps to reproduce, and whether they reproduce for other users or only for one person.
- The role list of the affected user and of any account that ran a job or rule involved.
- The relevant log entries copied as text, not described from memory.
- Any change made in the last cycle to roles, criteria, imports or schedules, even one that seemed unrelated.
Why does the same user get a different result on two days?
Often because something upstream changed between the two days, such as a value entered on a related record, a job that ran in between, or a reference rate that was updated. Compare the record’s change history for the two dates before assuming the logic is unstable. For reporting-specific causes of mismatched totals, see the notes on reporting solutions to common challenges.
Should we fix a symptom by editing the record directly?
Only as a temporary measure with a note on the record. A manual edit hides the cause, and the next calculation or import can reverse it without warning, so the underlying rule still needs fixing.
Can a notification problem be a people problem?
Often, yes. A sponsor who has left the organization or changed departments still appears as the recipient, and the notification is working exactly as configured. Check the user record before examining the rule.
When is it worth raising a problem as a design issue rather than a fault?
When the platform behaves exactly as configured yet the output misleads the decision being made. That points to the criteria or the data model, and fixing the configuration alone will not solve it. Wider implementation pitfalls of this kind are covered in the guide to ServiceNow implementation pitfalls.
Next step
If a problem survives two fixes, suspect the design before a single setting. The record, the schedule and the rule can be reviewed together.
ServiceNow SPM troubleshooting: tables, scheduled jobs and roles to check
Most Strategic Portfolio Management faults sit in one of five places: the project, program or portfolio record, the demand that spawned it, the resource plan, a scheduled job, or the notification rule.
The names below are typical out-of-box values, not guarantees. Check each one on your own instance and release before relying on it, since plugins, labels and defaults move between releases.
| Area | Typical name | What to read |
|---|---|---|
| Project, program and portfolio records | Tables pm_project, pm_program, pm_portfolio |
Read the state and parent fields to see where a roll-up total should come from. |
| Demand | Table dmn_demand |
Check the demand’s stage and the project it created before assuming a record was lost. |
| Resource plans | Table resource_plan |
Check the plan’s dates and the person it names before suspecting a capacity formula. |
| Scheduled jobs | Table sysauto_script with its active and run-as fields |
Read the last run result and confirm the run-as account is active and has the roles the job needs. |
| Import matching | Table sys_transform_map and its field maps |
Read which field map has coalesce set. With no coalesce, or the wrong one, an import can create new rows on every run. |
| Notification rules | Table sysevent_email_action |
Confirm the condition and recipients, then look for the message in sys_email. |
To place these checks in the wider module, read the guide to ServiceNow Strategic Portfolio Management; demand intake is covered under demand management and capacity questions under resource management.
Example (hypothetical): a resource manager says one analyst shows as fully booked although that analyst’s project ended. Open the resource plan records for that person, compare their end dates with the project’s end date, then check whether the plan came from the project or was added by hand. If a hand-added plan has no end date, it can keep counting, so the fix belongs to the plan and not to the capacity setting.
Which roles are involved in demand and resource work?
Common out-of-box role names include demand_manager and resource_manager, with project roles named differently by release and plugin. When a person cannot see or edit a record, open their user record, read their roles and compare them with what the module expects before changing any access rule.
Why does an import keep creating duplicate projects?
Usually the field maps have no coalesce set, or coalesce on a column that differs between runs, such as a name that people edit. Coalesce on a stable reference field so each source row matches one existing record.
How do I tell whether a scheduled job ran?
Open the job’s record in the scheduled jobs list and read its last-run information, then look at the system log for entries from the same time. A job that is inactive, or whose run-as account is inactive, may do nothing and may show no error.
Frequently asked questions
How do we know portfolio prioritization is working correctly?
For three months after go-live, track actual project outcomes vs. portfolio recommendations. Do highest-priority projects actually deliver higher value? Do resource allocations match recommendations? Use outcomes to refine prioritization factors.
What is the most common portfolio configuration mistake?
Failing to define clear business rules for prioritization before configuration. Teams rush to configure the system without agreement on how to prioritize. Result: prioritization produces rankings nobody trusts. Invest in upfront business rule definition.
How should we handle portfolio decisions that don't make business sense?
If the algorithm is recommending decisions that do not align with business strategy, the algorithm and business rules need adjustment, not the decision. Do not override the algorithm repeatedly; instead, fix the algorithm so it produces decisions that align with strategy.
Related guides
Related Oblytech services
Where this topic turns into delivery work, these are the Oblytech services that cover it.
Planning, running or fixing a ServiceNow programme? Tell us where you are and we will suggest a sensible next step.
Contact us