Pre-Requisites

• Please ensure the required Ivanti Connector has been created with the necessary permissions to support ticket actions. Please refer the Ivanti Service Manager Access Requirements Doc for details.
• Moveworks will require the following information for Service Request ticketing configuration which this guide will go through:
  • Name of the Service Request
  • Service Request’s subscriptionId
  • Service Request’s parameters

APIs Leveraged

Moveworks leverages the /api/rest/ServiceRequest/new API to create Service Requests.

The /api/odata/businessobject/ServiceReqsAPI is not supported.

Configuration

Step 1: Navigate to Ticketing

Start by navigating to Ticketing > Ticketing Setting > Ticket Mapping where you can create a new mapping for your ITSM system. Start by clicking on Create.

Step 2: Set Business Object Name

Now that we have the Service Request details from the customer, we can proceed with configuring ticketing.

Make sure that the “Business Object Name” is set to ServiceReqs

Step 3: Update Ticket Attribute Mapping

In Ticket Attribute Mapping under “Configure REQUEST ITEM”, we need to make the following mapping changes:

"display_ticket_id": "$TEXT(ServiceReqNumber OR ServiceRequests[0].strRequestNum)"
"id": "$TEXT(ServiceReqNumber OR ServiceRequests[0].strRequestNum)"
"state": "IF Status THEN Status ELSE \"Active\""

• The reasoning we do the above is due to the response payload we get back after submitting the Service Request POST call, for example:

{
    "IsSuccess": true,
    "ErrorText": "",
    "ServiceRequests": [
        {
            "bNew": true,
            "strSubscriptionRecId": "93A2E608E1E547258D9B1547CC1A5719",
            "strRequestRecId": "AF00AB63EF614F3EB81C6A9D07C4F2A1",
            "strIssueRecId": null,
            "strRequestNum": "4129688",
            "strName": "Generic Service Request",
            "strStatus": null,
            "strStatusId": null,
            "strService": null,
            "strServiceId": null,
            "strDetails": null,
            "parameterTemplateParameterIds": {
                "C58D88B143004901A00704AAF7B9651A": "94F2116EF5D34A24A15B39057A710A11",
                "05A4846CDDF3406A8628B762F77A5315": "0B9EB40FC9314DC99DE075F331937813",
                "CBC072ED9CE7475A9B56EBF918FB51B7": "2F9018201AA64647BE7DFF6963D0E111",
                "70C9C887E83049D794C97174D8A64126": "069052E6FC5F4028AF0FCC9BB6A26E16"
            },
            "DateApproved": null,
            "DateCancelled": null,
            "DateCompleted": null
        }
    ],
    "InvalidServiceRequests": {}
}

• As you can see, instead of Status and ServiceReqNumber, we get strStatus and strRequestNum. strStatus will always be null.

Step 4: Update Create Ticket payload

In “Create Ticket Payload”, fill in the payload information, for example:

{
  "serviceReqData": {
    "Symptom": "description",
    "Subject": "short_description"
  },
  "subscriptionId": "\"93A2E608E1E547258D9B1547CC1A5711\"",
  "attachmentsToDelete": "[]",
  "strUserId": "mw_user.requested_for.$TRIM()",
  "parameters": "{\"par-05A4846CDDF3406A8628B762F77A5311\": short_description, \"par-CBC072ED9CE7475A9B56EBF918FB5D11\": description}"
}

1. This should be automatically created but if not, verify that under “Workflow Conditions” your generate ticket workflow has the Conditional Action for the Request Item set, like:
2. You have completed the configuration ✅