- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-06-2017 12:20 PM
We are working on implementation of the PPM module and one of the things we'd like to do is relate each project to our organizational goals. I set up the goals in our system (Instanbul) by clicking on the goal lookup icon, selecting the "New" button from the goal list, and adding the goals there.
This is an extremely simple form with just a field for the goal description and a "State" value (choices are Pending, Achieved and Not Achieved). This is the OOB configuration for this form, which I verified by using an un-modified developer instance (below). In fact, if you go to try to personalize the form there are no other fields available to add to the form display.
Adding records here populates a table named "goal", which is related to the pm_project as a reference column. If you're an admin and dig into the dictionary configuration for the field on the pm_project form you'll see this in the reference qualifier for the goal column.
javascript:'sys_idIN' + getPortfolioGoalIds(current.primary_portfolio)
Basically, it says, when you want to assign a goal to a project, you're going to see a list of goals that are assigned to the same primary portfolio as the project that you're viewing. OK, fair enough. So the project has to be in a portfolio in order to lookup a goal and assign it to the project. But wait. The form where you enter goals doesn't display the portfolio field. And the general user doesn't have the ability to add the field to the form view because it hasn't been configured as one of the available fields, even though the field is present in the table.
So I'm thinking this is a bug, because there is a behavior being enforced by an OOB configuration (the reference qualifier above) and the field that's required to glue these things together isn't being exposed to the user so they can actually update it.
Am I missing something here? Some workflow that I'm missing or not following?
If, on the other hand, my analysis of this situation is accurate, when does something like this in SN rise to the level of being a bug vs a configuration change that administrators need to make to the OOB configuration? To me, this should just work, OOB. No configuration. No muss. No fuss. Why doesn't it?
And just to complicate matters a bit, there's also a table called "pm_portfolio_goal" that associates portfolio projects with goals. And the goals referenced in that table point back to the goal table as a reference. Maybe that is somehow the glue between the things that I can't make connect, but if so I'm not seeing exactly how to make it all work.
If anyone has any experience with this particular aspect of the PPM apps please let me know and help me sort out if this is something we should just fix, or should we report it as a bug that SN will fix for everyone. Thanks.
Earl
Solved! Go to Solution.
- Labels:
-
Project Portfolio Management
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-09-2017 12:55 PM
Emily,
Thanks for the response. I'm accessing the goals via the project form, using the goal field lookup feature, not via the portfolio form and the related list of goals. This is precisely the problem, and to a some extent, why I think this is a bug. Bear with me...
When you look at a project record, using the default form view, you can lookup a goal and add it to a project directly from that form. You can click the lookup icon next to the goal field and If there aren't any goals displayed in the lookup list you just click the "New" button from the list view to add one or more new goals.
The interesting part is that when you add goals this way this the portfolio is not recorded along with the goal, like it is when you add the goals via the portfolio related list. So the goals get recorded as not belonging to any portfolio. With that being the case those goals end up getting "lost" because the popup list on the project form looks up the goals by filtering on the portfolio that the project belongs to, and since the portfolio field in the goal record is null, nothing that was entered this way is ever going to be displayed in the goal list.
To add insult to injury, ServiceNow will add the goal the project during the process I mentioned above, irrespective of the fact that it doesn't belong to a portfolio, so it makes you believe it's working fine, when in fact you're just burying a data integrity problem that might not get discovered until some later time.
So bottom line is this. You shouldn't be able to add a goal via the project form without the portfolio being populated already, or being added at the same time. And most of all, ServiceNow shouldn't insert the goal records to the table with what has become a required field (via workflow/procedure) with a null/empty value.
There are a couple ways this can be corrected, by ServiceNow. First would be via a business rule that says that if the project doesn't belong to a portfolio then you can't add a goal. This could be done by making the goal field disabled unless the portfolio is non-null.
Alternatively, you could force the user to add the portfolio and add the goal at the same time, by presenting the goal form with the portfolio field displayed and making sure that portfolio value is passed back the project record.
I'm sure there are other ways of resolving this issue that I just haven't thought through yet as well. In any case, your response is greatly appreciated and is going to allow me to fix this in a way that will work for us. Thank you.
Earl
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-08-2017 03:31 PM
Beuller? Beuller? Bueller?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-09-2017 06:32 AM
Hi Earl,
I'm curious, what link did you use to get to the goal creation?
And also, are you on Helsinki or Istanbul?
I am pretty sure the answer is the same, regardless.. but wanted to check.
This does work, and it works by going to the Portfolio that you want to associate the goal with. There is a related list there.
When you click NEW from the related list, it establishes the relationship between the portfolio and the goal, such that you don't have to select it.
I don't think there was an intention for someone to create a goal outside the context of the portfolio, thus why it was designed this way.
So, i also don't think its a bug because it was intended to create the goal from the portfolio view to automatically establish the relationship.
LMK if you are seeing something different.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-09-2017 12:55 PM
Emily,
Thanks for the response. I'm accessing the goals via the project form, using the goal field lookup feature, not via the portfolio form and the related list of goals. This is precisely the problem, and to a some extent, why I think this is a bug. Bear with me...
When you look at a project record, using the default form view, you can lookup a goal and add it to a project directly from that form. You can click the lookup icon next to the goal field and If there aren't any goals displayed in the lookup list you just click the "New" button from the list view to add one or more new goals.
The interesting part is that when you add goals this way this the portfolio is not recorded along with the goal, like it is when you add the goals via the portfolio related list. So the goals get recorded as not belonging to any portfolio. With that being the case those goals end up getting "lost" because the popup list on the project form looks up the goals by filtering on the portfolio that the project belongs to, and since the portfolio field in the goal record is null, nothing that was entered this way is ever going to be displayed in the goal list.
To add insult to injury, ServiceNow will add the goal the project during the process I mentioned above, irrespective of the fact that it doesn't belong to a portfolio, so it makes you believe it's working fine, when in fact you're just burying a data integrity problem that might not get discovered until some later time.
So bottom line is this. You shouldn't be able to add a goal via the project form without the portfolio being populated already, or being added at the same time. And most of all, ServiceNow shouldn't insert the goal records to the table with what has become a required field (via workflow/procedure) with a null/empty value.
There are a couple ways this can be corrected, by ServiceNow. First would be via a business rule that says that if the project doesn't belong to a portfolio then you can't add a goal. This could be done by making the goal field disabled unless the portfolio is non-null.
Alternatively, you could force the user to add the portfolio and add the goal at the same time, by presenting the goal form with the portfolio field displayed and making sure that portfolio value is passed back the project record.
I'm sure there are other ways of resolving this issue that I just haven't thought through yet as well. In any case, your response is greatly appreciated and is going to allow me to fix this in a way that will work for us. Thank you.
Earl
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-14-2017 04:57 AM
Hi Earl Lewis Thanks for raising the problem. Yes the behavior you are seeing is not ideal. We will fix this in the upcoming release.
Thanks