Operational Plan Not Updating

melissacooney · 3 weeks ago

We are experiencing an issue when an operational resource plan is extended, the actual allocations do not include the new dates. This plan was extended to 9/25/2026, but the allocations end in June and I am unable to post time to the RPLN #. We did another extension adding a day and adding 1 more hour, and it created the allocation for September, but skipped July/August. Below are the screen shots of the first time we extended the date. After changing the dates a third time it finally worked, but any reason this happened in the first place? Would like to avoid having to update them over and over until it sticks. Thanks!

Vikram Reddy · 3 weeks ago

Hey @melissacooney,

Before you touch the end date on RPLN0011286 again, pull up the Resource Allocation related list on that plan, the one in your second screenshot, instead of trusting the note log on the plan form. The note log fires as soon as the end-date save succeeds and the Extension field flips to Allocated, that part is basically instant. Actually generating the monthly allocation rows is a separate step that runs after, and in your case it isn't keeping pace with the date change. Nine RALLOC records exist for that plan, the last one runs through 2026-06-30, even though the plan header and the note both say "Extension allocated until 2026-09-25." That gap, between what the plan record claims and what actually exists as allocation rows, is why you can't post time against July, August, or September. Look at the hours pattern in that same list too: 10 hours in October, 10 in November, then six straight months sitting at 0 Person Days, 0 FTE, 0 hours, then 1 hour in June. Your plan has Allocation type set to Monthly and Allocation spread set to Even, which is supposed to write one row per calendar month and spread the 21 Confirmed/Allocated hours proportionally across the full plan duration. Rows parked at zero in the middle instead of a proportional share point at the same regeneration gap: extending the end date is updating the plan header and adding a placeholder row for the new tail period, but it isn't reliably going back and recalculating the even-spread distribution for the whole span. That matches a documented platform issue, ServiceNow's own KB "Requested Allocations are not being created for Resource Plans" (KB1122077) covers allocation rows lagging behind an extended or edited resource plan. Worth opening a case referencing that KB number so support can tell you which recalculation job is failing to complete on your instance, rather than resaving the date until it happens to stick.

Until that's resolved, after every extension go straight to the Resource Allocation list and confirm a row exists for each new month before assuming the extension took. If a month is missing or sitting at 0, edit the Confirmed/Allocated hours on that specific RALLOC record directly rather than editing the parent plan's date again, that at least gets time posting unblocked without waiting on the platform to recalculate on its own.

References

Thank you,
Vikram Karety
Octigo Solutions INC

View solution in original post

Vikram Reddy · 3 weeks ago

Hey @melissacooney,

Before you touch the end date on RPLN0011286 again, pull up the Resource Allocation related list on that plan, the one in your second screenshot, instead of trusting the note log on the plan form. The note log fires as soon as the end-date save succeeds and the Extension field flips to Allocated, that part is basically instant. Actually generating the monthly allocation rows is a separate step that runs after, and in your case it isn't keeping pace with the date change. Nine RALLOC records exist for that plan, the last one runs through 2026-06-30, even though the plan header and the note both say "Extension allocated until 2026-09-25." That gap, between what the plan record claims and what actually exists as allocation rows, is why you can't post time against July, August, or September. Look at the hours pattern in that same list too: 10 hours in October, 10 in November, then six straight months sitting at 0 Person Days, 0 FTE, 0 hours, then 1 hour in June. Your plan has Allocation type set to Monthly and Allocation spread set to Even, which is supposed to write one row per calendar month and spread the 21 Confirmed/Allocated hours proportionally across the full plan duration. Rows parked at zero in the middle instead of a proportional share point at the same regeneration gap: extending the end date is updating the plan header and adding a placeholder row for the new tail period, but it isn't reliably going back and recalculating the even-spread distribution for the whole span. That matches a documented platform issue, ServiceNow's own KB "Requested Allocations are not being created for Resource Plans" (KB1122077) covers allocation rows lagging behind an extended or edited resource plan. Worth opening a case referencing that KB number so support can tell you which recalculation job is failing to complete on your instance, rather than resaving the date until it happens to stick.

Until that's resolved, after every extension go straight to the Resource Allocation list and confirm a row exists for each new month before assuming the extension took. If a month is missing or sitting at 0, edit the Confirmed/Allocated hours on that specific RALLOC record directly rather than editing the parent plan's date again, that at least gets time posting unblocked without waiting on the platform to recalculate on its own.

References

Thank you,
Vikram Karety
Octigo Solutions INC