Change Project from "On-Hold" to "Active" changes "Closed Complete" Project Tasks to "Active"

[richelle_pivec]

One of our team members alerted me to this weird behavior. After she changes the state of a Project from Active to On-Hold, it changes all of the Project Tasks to On-Hold (to be expected). However, when she changes the Project State from On-Hold back to Active, it changes all of the Project Tasks to Active, including the ones that were previously Closed Complete. As a result team members need to go in and re-close any tasks that have already been Closed Completed.

Does anyone know if this is expected behavior or where I can go to modify the script so it excludes the "Closed Complete" Project Tasks 

Thanks,

Richelle

[Uncle Rob]

On Hold isn't an OOB state for Project.  Knowing that, I'll bet good money the solution that pauses/unpauses your projects is also a customization.

If we're lucky, there will be a business rule that controls it.  Search your business rules for any that were created / updated by anyone other than admin

Does anything in that list look like a likely candidate for controlling this behavior?  If so, you can paste the script and we can get down to business.

[Tony DiRienzo · Accepted solution]

The Project State generally should not be set directly.  You should allow ServiceNow to calculate it. 

Project state is assigned to a specific "state bucket" based on the combination of the Project Task states.  Whenever you update the state of a Project Task, the Project's overall state bucket is recalculated, and if the state bucket changes the Project state will update accordingly (usually to whatever you have defined as the default state for that bucket). 

If you manually move the Project from one state bucket to another state bucket, a similar recalculation occurs in the opposite direction.  For example, if a Project is in a "Closed Cancelled" state, and you manually change it to "Open", the Project will move from the Closed state bucket to the Open state bucket.  The only way a Project's overall state bucket can calculate to Open is if all Project Tasks are in the Open state bucket, so in order to make your manual state change correct, ServiceNow will have to move all Project Tasks to an Open state.

I am going to take a guess here based on the behavior you've described:  "Active" is mapped to the Open state bucket in your instance, and "On-Hold" is either mapped to the Work in Progress state bucket, or you haven't mapped it at all.  When some Project Tasks are in the Closed bucket and some are still in the Open/Pending/Work in Progress buckets, the overall state bucket of the Project will always calculate to Work in Progress.  Having some tasks set to On-Hold and some to Closed Complete would allow the overall Project state to be set to On-Hold, since this is a Work in Progress state.  However, when you manually specify an "Active" state for the Project, ServiceNow cannot leave the Closed tasks in a Closed state, because you have specifically told it that the calculated combination of Project Task states must evaluate to the Open state bucket.  For this to happen, all Project Tasks must be in the Open state bucket.

With the London release, ServiceNow introduced new client scripts to prevent users from accidentally switching a Project from one calculated state bucket to another.  So a user will not be able to switch from "On Hold" (which is probably in the Work in Progress state bucket) to "Active" (which is probably in the Open state bucket), since this would force Project Task states to change.  Because of this, you will find that in London you must specifically map all of your custom states to a bucket or you will not be able to use them.

Here is some info about overall Project state bucket calculations:

• Open state bucket:  All children are in the Open state bucket
• Pending state bucket:  All children are in the Pending state bucket
• Work in Progress state bucket:  Children are either all in Work in Progress, or in any combination of various states
• Skipped state bucket:  All children are in the Skipped state bucket
• Closed state bucket:  All children are in the Closed state bucket

Here is information from the ServiceNow docs on how to map your custom states to the appropriate buckets:

Customize a state for project or project task

Useful tip:  It is possible to map a given state to more than one state bucket.  For example, in our instances, our custom On Hold state is mapped at the Project level (pm_project table) to both the Pending and Work in Progress state buckets.

[richelle_pivec]

You are correct in that "On-Hold" is our "Work in Progress." And I have found the new State Mapping feature in London and how to use it. I just didn't realize it was relating the Tasks to the Project and vice versa.

Given your great explanation, I should advise the team to only adjust states in the Project Tasks. If they want to put the Project On Hold, they should take one of their primary Project Tasks and put that "On Hold."

(Though when I just tested it out, putting the Project Task "On Hold," changed the Project State to "Work in Progress" which is a state we're not actually using.) So, I need to go look at that Script Include and see if I can map that to "On Hold" instead.

Do you think I should make the State field at the Project level "read-only" so that the Project Tasks drive it?

thanks,

Richelle

[Tony DiRienzo]

We considered going the "read-only" route, but decided not to do that, because our Project Managers wanted to still have some amount of control over the overall Project state.  We explained to them that ServiceNow will only allow them to change the Project state to another state in the same (calculated) bucket, and they were fine with this restriction (with the single caveat being the example explained below).

The mappings aren't controlled in a Script Include.  They are set in a dictionary override on the State field in the Task table.  You need to have overrides set for both the Project table (pm_project) and the Project Task table (pm_project_task). 

Based on the test case you explained (changing Project Task to "On Hold", overall Project state changes to Work in Progress), I would guess that your mappings on the Project Task table don't match your mappings on the Project table.  The state you choose at the Project Task level has to also be mapped to the state bucket that gets calculated for the Project level.  This is why I mentioned that you can actually map a state to multiple buckets.  Consider this example that we ran into:

We consider "On Hold" to be a Pending state at the Project Task level.  Imagine a Project with one Project Task.  If you set the single Project Task to "On Hold", the Project state bucket will calculate to Pending.  So we mapped "On Hold" to the Pending state bucket at the Project level.  When the Project Task is changed to "On Hold" ServiceNow sees a matching state at the Project level, so it sets the Project to "On Hold" as well.

However, what if you have two Project Tasks, one of which is "On Hold", but the other is "Closed Complete"?  The Project state bucket will calculate to Work in Progress, so the Project cannot be set to a state in the Pending bucket (where we put "On Hold").  But in this situation, our PMs wanted to be able to set the overall Project state to "On Hold".  Our solution was to map "On Hold" to both the Pending and Work in Progress buckets.  Now when they set the state of the open Project Task to "On Hold", ServiceNow sees states in two different buckets, so it sets the Project state to the default_work_state (which is "Work in Progress" unless you override it).  We have instructed our PMs that they may then manually set the state at the Project level to "On Hold", and ServiceNow allows this, since it also finds "On Hold" in the Work in Progress bucket at the Project level.

So even though "On Hold" is only mapped to Pending at our Project Task level, it can be selected at the Project level when the overall state is either Pending or Work in Progress.