(Reported with respect to ServiceDesk Plus build 9108 Enterprise)
Apologies if this is a duplicate topic, but I couldn't find this
mentioned when I searched the forum and known issues.
Background:
The 9.0 version of ServiceDesk included many new built-in fields
and ways of recording data in the new Change Workflows. When our
organization was using version 8.0 we had configured Change Additional
Fields to fulfill many of the same workflow functions. We no
longer use those custom Additional Fields in our Change Templates.
What we need to do:
We need to remove the fields from the Change Templates (while
having a historical entry of any use of the field maintained in Change
History for audit purposes). We also need to reclaim the
Additional Fields for other use (i.e. reset them to null and re-use
them when the need arises) because there are a limited number.
ServiceDesk behaviour that we appreciate:
Once we remove the
OriginalFieldName Additional Field (e.g. UDF_CHAR4 in
the database) from Change Templates, the values entered into the
field are deleted. Change History still says "
OriginalFieldName is modified from to
Value" - which we love because we need this audit trail.
Behaviour that causes us issues:
The problem is that as soon as we set the (e.g.. "
OriginalFieldName is modified from
x to
NewValue") Additional Field
configuration to null values (under the Change - Additional
Fields configuration wizard) then Change History entries
concerning UDF_CHAR4 disappear from Change History.
Additionally, if you then re-use UDF_CHAR4 Change
Additional Field by applying a new label (even without
installing the field back into Change Templates), the Change History
entry noted above ( "
OriginalFieldName is modified from
x to
NewValue") re-appears as "
NewFieldName is modified from
x to
NewValue", which is very confusing.
Suggested Enhancement
Would like the Change History entry, when using custom Additional
Fields (Change/Problem/Request), to capture the custom field label at
the time of the event and display that instead of displaying only the
current label assigned the UDF.
As there are a limited number of custom Additional Fields possible,
and the service management processes will ideally undergo Continual
Service Improvement, it makes sense to be able to re-use them as the
Change/Problem/Request documentation process evolves.