Custom Menu

Custom Menu

Custom functions can be executed using Custom Menu to perform a variety of user-defined actions within ServiceDesk Plus MSP Cloud and external applications.
You can configure custom functions for custom menu actions in requests, problems, changes, projects, releases, assets, CMDB, purchase, and contracts.


Supported Modules
Role Required
Requests
SDAdmin, SDSiteAdmin, HelpDeskConfig
Problems, Changes, Projects, Releases, Assets, CMDB, Purchase, and Contracts
SDAdmin
 

Configure Custom Functions for Custom Menu Actions

  1. Go to Setup > Developer Space > Custom Functions.
  2. In the module drop-down, select Custom Menu Actions.
  3. Click New Custom Function. You can alternately write the custom function while creating/editing a custom menu.
  4. Fill out the necessary information as described in the below:
Field
Description
Custom Function Name*
Provide a unique name for the custom function.
Description
Describe the objective and usage of the custom function.
Applies to
Choose the sub-entities within the module where the custom function is applied.
Deluge Script Editor
Compile the custom function in the Deluge Script Editor using a simple drag-and-drop motion. To learn more about Deluge and how to write custom functions, click here.
Depending on the module selected, the following arguments will be passed in the custom function.
  1. Requests - 'requestObj' and 'context'
  2. Problems - 'problemObj' and 'context'
  3. Changes - ' changeObj ' and 'context'
  4. Projects - 'projectObj' and 'context'
  5. Releases - 'releaseObj' and 'context'
  6. Assets - 'assetObj' and 'context'
  7. CMDB - 'ciObj' and 'context'
  8. Purchase - 'purchaseorderObj' and 'context'
  9. Contracts - 'contractObj' and 'context'
'[module]Obj' - Stores the details of the module on which the custom menu must be configured. 

'context' - Stores the current instance and the logged-in user details. 

Info
If the custom function is configured for a module sub-entity, the respective sub-entity object will be passed in the parameter. 
*mandatory fields
After compiling the custom function, click Save or Save & Execute Script.

Points to remember:

Ensure custom function returns "Map" value.

Info
Note that you can update only the following request fields in requestObj: subject, resolution, mode, group, item, level, impact, service_category, update_reason, priority, udf_fields, impact_details, subcategory, status, request_type, description, urgency, technician, category. 
You cannot return any object from the custom function to modify the request. You can, however, modify the request by making API calls.

Test Execution of Scripts

After writing the custom function, you can test it by following the steps given below:
  1. Click Save & Execute Script.
  2. Choose a sample request from the list of requests displayed.
  3. Click Next.
  4. The data that will be passed to the custom function will be displayed under the parameter 'requestObj'. Optionally, you can modify the requestObj values.
  5. Click Execute.
The script will be executed, and the output will be displayed.
Info
Test execution of a custom function does not affect any data in your production account. However, if you make any API calls (by using zoho.sdp.invokeurl or invokeurl) while testing the custom function, the API will be invoked. Make sure you don't invoke an API that might result in unintended consequences. 

Debugging Tip

Deluge allows debugging through an action called info. You can use this action to print the output of your custom function.
For example, to understand the structure of requestObj and context, you can simply run the following script and study the response.
  1. info requestObj;  
  2. info context;
  3. return true;
 

Sample Script

The new field values must be returned from the custom function in a specific format as demonstrated in the following sample script that can be used to auto-close linked requests upon the closure of the reference request:
  1. /*Gets the request status*/
  2. status = requestObj.get("status").get("name");
  3. returnMap = Map();
  4. /*Checks if the request is closed*/
  5. if(status.equals("Closed"))
  6. {
  7. /*Gets the name of the portal in which the request is logged*/
  8. portal_name = context.get("instance");
  9. request_url = "/app/" + portal_name + "/api/v3/requests/";
  10. /*Checks if the request has been linked to other requests*/
  11. if(requestObj.get("has_linked_requests").equals("true"))
  12. {
  13. /*Specifies criteria to fetch the linked requests*/
  14. linked_request_criteria = {"field":"linked_to_request.request.id","condition":"is","value":requestObj.get("id")};
  15. not_closed_criteria = {"field":"status.name","condition":"is not","value":"Closed","logical_operator":"and"};
  16. /*Makes an API call to fetch the 10 oldest linked requests*/
  17. fetch_response = zoho.sdp.invokeurl
  18. [
  19. url :request_url
  20. type :GET
  21. parameters:{"input_data":{"list_info":{"row_count":"10","sort_field":"display_id","sort_order":"asc","search_criteria":{linked_request_criteria,not_closed_criteria}}}}
  22. ];
  23. requests = fetch_response.getJSON("requests");
  24. request_ids = "";
  25. /*Gets the IDs of the requests that are fetched*/
  26. for each  request in requests
  27. {
  28. request_id = request.get("id");
  29. if(request_ids == "")
  30. {
  31. request_ids = request_id;
  32. }
  33. else
  34. {
  35. request_ids = request_ids + "," + request_id;
  36. }
  37. }
  38. if(request_ids != "")
  39. {
  40. /*Makes an API call to close the requests that are fetched*/
  41. close_response = zoho.sdp.invokeurl
  42. [
  43. url :request_url + "close"
  44. type :PUT
  45. parameters:{"ids":request_ids}
  46. ];
  47. if(close_response.get("response_status").get(0).get("status") == "success")
  48. {
  49. returnMap.put("success",true);
  50. returnMap.put("message","Child requests are changed successfully");
  51. }
  52. else
  53. {
  54. returnMap.put("success",false);
  55. returnMap.put("message",close_response.get("response_status").get("message"));
  56. }
  57. }
  58. }
  59. }
  60. return returnMap
As demonstrated in the above sample script, after the custom function is executed, you can optionally prompt the user of the success or the failure of the action execution by including the following section in the script:

  1. {"success": true/false, "message": "<custom message>"}

    • Related Articles

    • Custom Menu

      Overview Custom Menu allows you to create customized actions that can be performed on various modules in ServiceDesk Plus MSP Cloud. You can configure actions for a custom menu by using custom functions, custom widgets, or by invoking a URL. The ...
    • Custom Views

      Custom views allow you to filter data in a module based on specific conditions to create your own customized list view, template view, or kanban view pages. Role Required: Technicians with View permissions Go to the respective module. Click the New ...
    • Custom Views

      You can filter the change requests based on specific criteria to create your own customized page of change requests. This helps you sort and view change requests based on your priority and requirement. Role Required: SDAdmin, SDChangeManager, User ...
    • Custom Views

      Custom Views Create a customized list or template view that filters and displays only releases matching a specific criteria. This helps you sort and view release requests based on your priority and requirement. Role Required: SDAdmin, ...
    • Custom Functions

      Overview Custom functions allow you to manipulate data within ServiceDesk Plus MSP Cloud and external applications. You can use custom functions to configure complex conditions or define multiple actions. For example, data under any module can be ...