You can try to catch the subcategory in some variable say $L.subcat_temp and the use this in next wizard to build query. But here concern is that how would you build the sql (mentioned in expression tab named, $L.temp.sql) to build the query. As it is not easy to get the subcategory from structured array in template record.
____________________________________ Assign Kudo, if found post useful and mark it accepted if solves the issue.
So here's how we solved that in our environment; this isn't a line by line code, but it's the general approach we used that works.
First, we created a new table that houses all the template categories (similar to the 'category' table used in Interaction and Incident). We went one step farther and actually created Subcategories as well, so we created a table for that, similar to the subcategory table used in the other modules.
Then, like you did, we created a field on the Template table to house the category value and subcategory value.
Then, after renaming the OOB wizard, we modified the original Template.select wizard to do the following:
$L.file passed in
Usage - select one record from the list
Selection Criteria = Query for Records, querying our custom table for the categories that apply for that module (Incident templates vs Interaction vs Change vs Problem, etc).
Perform actions on Current File, and use expressions to generate the query we will pass to the next wizard that displays all the Templates that match the query criteria. In this case, we were looking for the Subcategory records for this module that match the selected category value.
Then we go on to the next wizard.
That wizard, like the first, has the $L.file passed in, and we're going to query for the subcategory records based on the module and the category. Then, we present the user with the subcategories that match their selection. Once they make that selection, we then call the final wizard, which is the like the OOB wizard 'Template.select'.
Because of the previous wizards, we have been able to modify the value of the $L.query variable based on our selections in the previous two wizards, so when the final wizard runs, it only shows the Templates that have the same category value that was selected in the first wizard and the same subcategory value that was selected in the second wizard. Once the user selects the Template here, the rest flows as OOB.
We did something similar way back in SM7 when a customer with about 4,000 assignment groups wanted to filter templates by assignment group (by adding an assignment array to the Template in addition to the user roles array). This assumes you've added subcategory as a field in the Template record. This approach does not require a secondary reference table, but that may be more scalable.
In the Wizard Template.select_1, you could:
add an initialization expression similar to:
if filename($L.file)="incidents" and not null(subcategory in $L.file) then $L.appendQuery=" and subcategory=subcategory in $L.file" else $L.appendQuery=""
Then update the Query for Records expression on the Usage tab. Change it from:
tablename=$L.filename and (null(role) or role=$G.user.role) and evaluate(parse($L.query,2))
tablename=$L.filename and (null(role) or role=$G.user.role) and evaluate(parse($L.query,2)) + $L.appendQuery
As written, they will only see templates with the same subcategory if there is a subcategory. If you would want them to also see templates which have no value in the subcategory field, you could model the way role is queried for null or user role).
Another option would be to have Template.Select go to a differnt Wizard for Interactions (in the Next Wizard tab) and then just update that wizard's query. The Template.Select_Interactions Wizard would be exactly the same as Template.Select_1 except for the revised query. All other files would stil use Template.Select_1.
We routinely update the templates so that the service desk can mark an interaction template as "available in ess" and add a branch to the wizard to display only ess templates in the ess.do client regarless of the user's assigned role. This ensures that interaction templates with a blank user roles array do not appear in ESS by default and that a user whose full client role would restrict their template access will still see all ESS templates.
Thanks @all. Your advices let me solve the request... ... but brought me to the next question:
"Apply Template" is started to DisplayOptions(DO) by action "applyTemplate".
To run different Apply Template Wizards in Interacions/Incidents/Change i wanted to call the Wizard through RAD App wizard.run in DO.
If i call the wizard here, it is started and it shows up the templates according to my query but the Template is not applied to the record (in this case: interaction)?! No field in the record is filled by the values defined in the template.
Perform Actions On is the label for the options 'Current File ($L.file)', 'Select ($L.selection)', or 'Each Record in Selection ($L.selection)'
Reset current file to selections means that, when the wizard finishes, will it go back to the place you started from, or will it use the record in your Wizard's selection list as the new $L.file. If this is set to true, when the wizard finishes, the user will be left on the record selected within the wizard. If this is null or false, the user will return to the record they were on when the wizard started; everything the wizard DID to the record will still be done and visible.
parse() is a RTE function that tells the system to treat the value of $L.query like it's an expression, instead of a string.
See the Help Documentation on the different variable types. Search for 'variable' in the help.