Which product are you working with?
This particular space tends to just get visibility for Community related website requests/questions. If you let me know which product you're working with, I can move this to the corresponding space so it gets some better visibility.
Thank you for your message. The product we are using is
Ivanti Service Manager
2017.2.1.26741 @ Built On 2017/08/28 UTC Deployed On 2017/09/07 23:21:59 UTC
Copyright (c) 2005-2017 Ivanti. All Rights Reserved.
2 of 2 people found this helpful
I will first of all say this is perhaps not the ideal method of achieving this or what you had in mind (or myself for that matter!). I am fairly annoyed at myself that I didn't find a way to achieve this validation within the request itself.
As I couldn't find a way to configure this within the Offering, I looked to Validation Rules. I was interested in ServiceReqParam as this is where the Template parameters are parsed for the Service Request itself.
To give a bit of background as I am unaware if you have had any exposure to this, each ServiceReqParam record will have a Parameter Name (aka Unique ID within the Offering) and a Parameter Value. I modified a previous Offering I had for testing and setup a field with the Unique ID of 'Debug' (the unique part is important here):
Then I setup a validation rule against ServiceReqParam:
The error message recieved is not exactly user-friendly but it does appear to function as intended.
Thank you very very much for your advice. This is very useful.
I've not done this sort of thing before, and I'm getting confused what the ParameterName and the ParameterValue should be.
I know you have provided a description, but what is the ServiceReqParam exactly? I've not come across this before, and the Help file isn't really helpful.
If you have time, could you please provide a detailed description/example.
Many thanks for your help so far.
No problem Marcel, some elements of the system appear not to be designed for customisation yet, strictly speaking, it is possible.
ServiceReqParam itself is a Business Object. The purpose of this is to hold the value of parameters associated to a Service Request. The parameters are defined within Request Offerings.
This is an example of a Request Offering:
In this example, the Parameter Name is 'RequesterDepartment' as defined by the Unique ID. The Parameter Value is set at runtime when populated by a user, these can be viewed within Service Requests via a plugin, 'Parameters'.
So what we are looking at above is actually the ServiceReqParam records for this Service Request, and there are 2. Seeing this in the database may help to understand:
As you can see, there are 2 records. First, we have the GUID on the far left for the ServiceReqParam record itself. Next, is the foreign key to ServiceReq, linking this directly to a ServiceReq record.
Lastly, we have the ParameterName & ParameterValue values.
This was a simple example and as you probably imagine there would be many more ServiceReqParam records for complex Offerings, however I hope this helps explain the concepts.
I should add, I don't think this is intended learning for Administrators which is supported, as you rightly point out, by the fact there is little support documentation on this topic. As such, please note that this information is largely based on how I have connected the dots and using what information I could find. With that in mind, if you do some digging of your own and discover anything interesting, please share! I am always willing to learn more about the system and to be proved wrong (as it helps to learn! ).
Thank you so much for the additional advice. I have now got it working as i wanted it to work.
Your help is much appreciated, and if/when I do find out more about configuring HEAT, I'll be in touch.