Updating Service Requests with Application Integrations

Document created by Ramon Geertjens Employee on Mar 29, 2018Last modified by Ramon Geertjens Employee on Sep 14, 2018
Version 13Show Document
  • View in full screen mode

As part of a Service Catalog workflow, you can include Applications Integrations, to push out API calls to external sources and the internal Samanage API.
As part of the API call, you may include Variables of the Service Request being raised. 
The Variables are written in the form of {{variable name}} within the body, and are replaced with their values just before the command is sent. You can now also use the new variable {{context_id}} that leverages the Samanage API to make updates to the current Service Request. Or create other objects and automatically link this Service Request.

Here are all the variable names that can be used:









Department API ID


Service request id respectively, of the incident.


Any Service request variable, eg: first name, title.

{{first name}}, {{title}}

Please note that all Service Request variables are Capital Sensitive!


Below are multiple use cases that use the new variable as well as existing variables. These use cases can be used as a reference for improving your Service Request Workflows.


Change the Service Request title

When a service is requested you can use the Application Integration to change the Service Request name. For instance, when an onboarding request comes in, you can add the new employee name to the title of the Service Request.


To do this, use the {{context_id}} variable in the URL of the Application Integration. In the body, you can use the variables of the custom values from the service request. In this example that is {{first name}} and {{last name}}.



 "incident": {

   "name":"New Hire: {{First name}} {{Last name}}"}


This Application Integration can be triggered as a first step in the Workflow to automatically trigger upon the creation of the Service Request.

Add CC to the Service request
You can add 1 or multiple CC's to the Service request.



 "incident": {





<incident><cc type= "array"><cc>example@samanage.com</cc></cc></incident>

Post private or public comments in a Service Request

You can add an automated comment to the Service Request after a task/approval is completed. This automated comment can be used to update the Service Agent user or the Requester. You can either post a Private or Public comment to the Service Request. You can use an Application Integration step like this:



 "comment": {

   "body":"User has been created",





<body>User has been created</body>

Update the state of the Service request

After you send a comment you can automatically change the state of the Service Request. This can also be used to change the status to “Awaiting approval” when an approval needs to be done and change the status to “Approved” or “Declined” after the approval is handled.
In order to achieve this you can use an Application Integration step like this:



 "incident": {

   "state":"Awaiting Input"



Create an Incident/Change and relate the originating Service Request
From the Service Request workflow, you can automatically trigger the creation of an ITSM object (Incident, Problem, Change, Release) and relate the Service Request to this object.
This can be of value when you want to create a Change only after this has been approved by the CAB. You will then get a process like this:

In the Application Integration you can use the {{context_id}} in order to relate the Service Request to the ITSM object.



 "incident": {

   "name":"Created from incident ((context_id}}",


   "category":{"name":"Incident category"},
   "subcategory":{"name":"Incident subcategory"},


   "description":"Incident description",




Reassign the Service Request

You can now build into your Workflow the re-assigning of the service request. This can be done after completion of certain tasks/approvals or based on Condition Sets. In the example below,  the Requester had the option to choose a new MacBook or a new Surface Pro. In this example, John is handling all new Macbook requests and Peter is handling all new Surface Pro requests. By using the {{context_id}} you can consolidate these requests and provide automatic reassigning for a streamlined and efficient process.


"incident": {

Create a Purchase Order and link the Service request

Within the Service Request, you can now create a Purchase Order and link the Service Request to it. This can be of value when equipment needs to be ordered in order to complete the service. This step can be automated with the use of the Purchase Order API and the {{context_id}} variable. This Application Integration will look similar to the ITSM object creation and relating.


Create an asset and link the service request and the requester

After the Purchase Order is approved you can automatically create the asset that was purchased and installed and relate the Service Request to it via the {{context_id}} variable. This Application Integration will look similar to the ITSM object creation and relating.


These are just some of the use cases that can be implemented with these variables. The possibilities with this are endless and can be fully customized to your organization. Please feel free to reach out to your customer success manager or our support department if you have any specific questions.

Map Variables to Custom fields on the Service Request
You can leverage application integrations to map variable content to custom fields on the service request object.


{"incident": {

   {"name":"Custom field name","value":"content"}]



Use case

We documented a use case with Application integration Here!

6 people found this helpful