Custom bind variables

It would be helpful if we could define custom bind variables in Maximo.

Examples:

• &FIRSTNAME&

• &ISINTERACTIVE&

• &ENVNAME& (i.e. the Maximo environment name; not the same thing as the existing :&HOSTNAME& variable).

Use Cases:

• Easily send an email with a person's first name.

• Or, in a conditional expression in a global data restriction, determine if the session is interactive or not -- without the need for a custom automation script.

• Or, send an email with the true environment name in it (not the host name)

(From Steven S.)

You can already use &SYSDATE& for example to get the current date time.

But let's say you want your saved queries to retrieve work for the current week and your week is Monday to Sunday. Writing the SQL for that is hard for an end user because it's database platform dependent and typically involves calling multiple SQL functions to do. But if I created a variable like &MONDAY& that I populated with the date for Monday of the current week using Java calendars it would make it easier for the user to utilize in a saved query without having to understand complicated SQL logic.

If the bind variables expand into default values, that's another good area where things can be improved. I've seen customers want to default a date to current date + 7 days for example and you can't do that with the bind variable so you have to write an automation script for a relatively simple default.

This also applies to start centers where you have can change the color options but can only use < or > the current date. But some might want to add or subtract days from that to control the highlighting (IE is it overdue by 30 days). This specific example we're going to look at as part of the modernization effort of start centers but would be addressed if custom bind variables were supported.

Another good example not related to dates that I didn't see on your list is something like &DEFAULTSITE&, though I'd like to see that get added to core vs being a special user defined function. There's a lot of examples (especially in the mobile products) where this is retrieved via a subquery to MAXUSER which isn't terrible but seems like something that should be used from the cached UserInfo instead.