There is no out of the box "Date Closed" field, at least not in our 14.2 on premise solution.
If your setup is the same as ours, then you'll also need to create a custom "Date Closed" field. Make the "Date Closed" field read-only and then populate it using the process suggested by Michael Thibault. Sorry if you already understand this - I think, from what I read, that there is an assumption that custom fields must be created - just wanted to make sure and not assume. An alternate solution might consider renaming "Date Resolved" to "Date Closed" - this I don't recommend (see below).
As risks and issues reside in separate objects, you'll need a "Date Closed" field added to each object, and processes for each object.
Of course, as soon as you close a risk or issue and set the "Date Closed," someone will want to reopen the risk or issue - they may have closed it by mistake or someone higher up will disagree with its closure. So, please consider adding a process that will delete the date from "Date Closed" if/when the risk or issue is re-opened. You may also want to put "Date Closed" on the Audit Trail, if you find that resources are closing and re-opening risks or issues often. If they are not doing this often, then perhaps remove "Date Closed" from the Audit Trail when its no longer helpful to track.
If you are thinking about renaming the out of the box "Date Resolved" attribute to "Date Closed," I do not recommend this:
- some companies (mine, was one) want to close an issue after it has been resolved - that is how we always did before in Excel....
- but, in CA PPM, when the status is changed from resolved to closed, the "Date Resolved" field gets cleared by a hidden process or bit of code
- Therefore, "Resolved" and "Closed" are, must be, two very distinct end states:
- Resolved: Work has been performed to solve/mitigate issue or risk and the work was successful, perhaps lessons learned are also recorded.
- Closed: Risk or issue was canceled - perhaps it was created as a mistake, a duplicate or in the end, customer didn't agree that issue or risk existed - nothing was done, no lessons learned.
- So, later, when searching history for lessons learned, it is helpful to have risks/issues marked resolved vs. closed. If they are all marked closed, the "Date Resolved" field is blank and there is no easy way to filter for lessons learned. Yes, you may be able to force a date into "Date Resolved" field with a process that starts when status is changed to closed, but then one still loses the ability to easily sort for lessons learned amongst the resolved risks/issues. Of course, one could add a 'lessons learned' check box, but why ask the user to fill in yet another field? Ours already complain that there are too many fields.
I took awhile for our users to fully grasp why we had to distinct end states, Resolved vs. Closed. But today, its pretty much common knowledge, a given.