Automate Android Kiosk Troubleshooting Workflows with AirDroid and ServiceNow

Retail, restaurant, and self-service businesses use ServiceNow to classify, assign, and track IT Incidents. When an Android device unexpectedly exits Kiosk Mode, however, having a ticket is only the first step. The ticket also needs enough information for someone to act on it. Even if an Incident was created manually or through an existing rule, the technician still needs to identify the device and store, check whether the device is still outside Kiosk Mode, and see whether anyone has already tried a reboot or another recovery action.

If that context is not passed to ServiceNow when the event occurs, technicians have to look for it across the ticketing system, the device management platform, and communication tools. Repeated triggers may also create several Incidents for the same fault, leaving the investigation, actions taken, and recovery result scattered across separate records. The ticket may be in the queue, but work on the device has yet to begin.

This article uses ServiceNow to show how AirDroid Business fits into an existing ITSM process. The resulting workflow covers Incident deduplication, creation, assignment, handling, recovery checks, and status updates.

1Why Android Kiosk Incident Response Needs MDM and ITSM Integration

MDM ITSM integration brings device context and recovery results into the Incident process. For teams managing a large Kiosk fleet, this changes how they detect, assess, handle, and verify each event.

The integration can:

• Shorten response times: A Kiosk exit can reach ServiceNow with the device, store, screenshot, event time, and current status already attached, so technicians can start troubleshooting sooner.
• Cut manual work: Technicians no longer need to look up and copy the same information between two systems. They can start from the device details in the Incident.
• Prevent duplicate tickets: Before creating a record, the workflow checks for a related active Incident and updates it if one already exists.
• Make recovery more reliable: AirDroid Business can check the Kiosk status again and write the result back to ServiceNow. That result determines whether the Incident should be updated, escalated, or resolved.
• Support fleet-wide management: A consistent record of events and actions helps IT teams spot devices and stores with recurring problems, compare remote handling with on-site support, and refine classification rules, maintenance plans, and support resources.

ServiceNow still manages Incident priority, ownership, SLAs, and lifecycle. AirDroid Business monitors Kiosk status, gathers device information, performs reboots or supports remote troubleshooting, and checks whether the device has recovered. Connecting the two systems helps urgent events reach the right queue sooner, reduces repeated lookups, gives stores a consistent response process, and ties Incident resolution to the device's actual recovery status.

2Kiosk Incident Auto-handling Workflow at a Glance

Once UEM and ITSM are integrated, an MDM automation workflow can investigate a Kiosk exit, create or update an Incident, support troubleshooting, and write back the result. It handles repeated searches, ticket creation, and status updates automatically. Technicians step in when the situation calls for judgment or hands-on action.

The diagram below shows the full workflow between AirDroid Business and ServiceNow. The next section walks through the setup.

3How to Build an Automated Kiosk Incident Workflow with ServiceNow

1 Create an Automation Task Triggered by an Event

In the AirDroid Business Console, open Task & Automation and create an Automation Task. Choose Event as the trigger.

In the event list, select Kiosk and set the condition to Not in Kiosk. You can also set monitoring hours. For example, a store can monitor Kiosk status only during business hours, so the task does not run while the store is closed.

2 Select the Device Scope

Select the devices or device groups that the task should cover. Start with one test device or a small test group, and exclude:

• devices undergoing maintenance or upgrades;
• decommissioned devices, devices awaiting collection, and devices that are no longer in use;
• internal test and demonstration devices; and
• devices that have not received the target Kiosk configuration.

If stores have different support teams, ServiceNow Business Services, response targets, or Kiosk configurations, split them across separate Automation Tasks. Putting every device into one task may seem easier, but the routing and field mappings soon become difficult to maintain.

3 Use the Kiosk Exit Incident Response Template

The Handling Plan has three options:

• Device Action: Run one device action, such as a reboot or reset.
• Email Notification: Send an alert to selected email recipients or groups.
• Automation Workflow: Run a workflow that combines device queries, conditions, human input, and follow-up checks.

For this setup, select Automation Workflow, then choose the Kiosk Exit Incident Response template.

The template already includes the response logic:

You can keep this event detection, device investigation, and handling logic when you connect the template to ServiceNow. The ServiceNow Incident takes over the information handoff, assignment, and result tracking previously handled by email. Any email, in-product alert, or escalation notification should follow the notification and SLA rules already set up in the organization's ServiceNow instance.

4 Adapt the Template for ServiceNow

Step 4.1: Configure the Required Connections

Go to InsightFlow > Credentials and create separate AirDroid Business and ServiceNow credentials.

1. Select Create.
2. Enter a credential name and description in Basic Settings.
3. For ServiceNow, select ServiceNow Basic Auth API as the credential type.



4. Enter the ServiceNow authentication details required by the page.
5. Under Permissions, choose who can use the credential.
6. Create or select the AirDroid Business credential in the same area.

Make sure both credentials show a Valid status. Back in the workflow, use the AirDroid Business credential for device query and action nodes. Use the ServiceNow credential for nodes that search, create, or update Incidents.

Step 4.2: Replace the Initial Email with ServiceNow Incident Actions

Find the Send Administrator Investigation Report email node and replace it with these nodes:

• Add Get Many Incidents to search for an active Kiosk Incident for the same device.
• Add a condition node to check whether the search returned a match.
• If it did, run Update an Incident.
• If it did not, run Create an Incident.
• Add the investigation summary, screenshot link, and handling form link to the Incident.

Do not create a new Incident every time the task runs. If the same device exits Kiosk Mode several times in a short period, this would produce duplicate tickets.

Step 4.3: Reuse the Existing Report Outputs

The template's compile nodes already assemble the device, store, screenshot, Kiosk status, and handling results. When you replace an email node, reuse the same Subject and Body outputs in IncidentData. There is no need to query the device or rebuild the report. Technicians will see the same investigation details in the Incident and can open the handling form from there.

For example, Compile Device Investigation and Generate Administrator Report returns:

  

    copy
    Copied!
  
  

  AdminSubject
AdminBodyBeforeForm
AdminBodyAfterForm
AdminFormSummary
ScreenshotUrl
ScreenshotTime
  
  
  

The original email node uses these values for its subject and body. When you replace that node with Create an Incident, map the same values to IncidentData:

  

    copy
    Copied!
  
  

  {
  "short_description": "{{#DEVICEOK.AdminSubject#}}",
  "description": "{{#DEVICEOK.AdminBodyBeforeForm#}}\n{{#CREATEADMIN.FormUrl#}}\n{{#DEVICEOK.AdminBodyAfterForm#}}",
  "correlation_id": "{{#NORMALIZE.DeviceId#}}"
}
  
  
  

In this example:

• Use AdminSubject as the Incident short description.
• Add the investigation report and FormUrl to the Incident description.
• Use DeviceId to identify the device and search for duplicate Incidents.

Use the same approach for later results. Compile Restart Unrecovered Explanation already produces FollowupSummary. Replace the restart failure email with Update an Incident, then write that output to Work Notes:

  

    copy
    Copied!
  
  

  {
  "work_notes": "{{#NORMALIZE.DeviceName#}} was not confirmed as restored after restart.\n\n{{#FORMATPOSTRESULT.FollowupSummary#}}"
}
  
  
  

When configuring Update an Incident:

• Use the Incident sys_id returned by Get Many Incidents for IncidentSysId.
• In IncidentData, reuse the Subject, Body, and compile-node outputs from the email node you replaced.

Replace the remaining email nodes in the same way:

• In the Restart branch, replace recovery and recovery-failure emails with Update an Incident.
• In the Remote Support branch, replace the remote-link and link-failure emails with Update an Incident.
• In the On-Site Support branch, replace the on-site notification and final feedback emails with Update an Incident.

Point every later Update an Incident node to the same IncidentID. Write the original Subject, Body, or output from the preceding compile node to work_notes. Leave the device actions, handling form, conditions, and recovery checks unchanged.

Once these nodes are replaced, ServiceNow stores the investigation details, handling links, and final results in the same Incident, rather than leaving email as the main record.

5 Add ServiceNow Actions (Optional)

The basic workflow needs only Get Many Incidents, Create an Incident, and Update an Incident. Together, they handle duplicate checks, Incident creation, and result updates.

If the organization's ServiceNow process relies on other records, add the actions that the instance requires:

• Add organization and service data: Use Get Many Departments or Get Many Business Services to find the relevant record.
• Associate the affected asset: Use Get Many Configuration Items to link the Kiosk device to the correct Configuration Item.
• Route the Incident to a support team: Use Get Many User Groups to find the intended Assignment Group.
• Work with custom records: Use Table Record when the organization stores device, store, or support data in a custom ServiceNow table.
• Attach a file: After the Incident exists, use Upload an Attachment if the workflow needs to add a local report or screenshot file.

Reference fields usually require the record's sys_id, not just its display name. These actions are optional, so add them only if the ServiceNow instance uses the corresponding fields, tables, or routing rules.

6 Test and Publish the Task

Run the full workflow on one test device before you publish it to production:

Before publishing, also check that:

• Get Many Incidents checks a stable device ID, event type, and active state so that it does not create a duplicate or update the wrong Incident.
• Reference fields such as Department, Business Service, Configuration Item, and Assignment Group use the sys_id returned by ServiceNow.
• A failed ServiceNow write remains visible as an error. The workflow must not treat that failure as a handled Incident.
• The workflow resolves an Incident only after the device returns to the expected Kiosk state.
• If technicians will choose a handling path in ServiceNow and that choice must trigger an AirDroid device action, you also need polling, a callback, or another way to return the choice to AirDroid Business. Replacing the email nodes alone will not do this.
• Other ServiceNow actions for Department, Business Service, Configuration Item, User Group, Table Record, or Attachment are added only when the process needs them.

4Conclusion

Teams already using ServiceNow do not need to change their Incident Management process. AirDroid Business detects the Kiosk exit, collects device information, supports reboots and remote troubleshooting, and checks the recovery result. ServiceNow continues to handle deduplication, assignment, tracking, and resolution.

The existing Kiosk Exit Incident Response template already contains the device investigation and handling logic. The team only needs to replace its email nodes with the corresponding ServiceNow actions. Test duplicate checks, field mappings, and all three handling paths on one device or a small group first. Expand the rollout only when the Incident status consistently matches the device's actual recovery result.

Share: