💡 Nexthink Device Management Ambient Agents

At Leidos, we did the teams cache reset capability - but i like this proactive approach, i will see if the team wants to enhance it.  Our team is currently working on a nexThink capability to do hardware attestations, we have to do these every 6 months as employees , so we have the agent checking the due dates from ServiceNow, getting the serial number from the device, the user email and asking NexThink if the user has logged into that specific machine in the last 7 days, if it has , the agent will complete an auto attestation for them handle the service now RITM associated and capture the details in an audit log. If the agent successfully does the auto attest, its sends the user a notification telling them what happened and hte associated RITM.  If the bot can’t do the attestation , it doesn’t send the user anything and just relies on the normal workflow of the user receiving emails from SN or a notification from the chatbot.

• Nexthink automation for six‑month attestations in development.
• Agent workflow: check due date (24 days out) → get hardware serial & user email → query Nexthink → auto‑attest if logged in within 7 days → complete RITM → audit log → notify user.
• If auto‑attest fails, standard notification/workflow remains in place.

Awesome use case ​@jaime.renn. Including the ServiceNow ticketing portion as well for tracking is a great addition that can be included in any of these use cases!

​@rgeroulo thanks for the info! Curious when it would make sense to utilize these use cases vs A2A (with Spark AI) functionality. I know we don’t have A2A available yet, but I’d love to hear your guidance on how to think about these different workflow options. 

​@mrukavina great question!

Ultimately, Spark AI utilizes the same Remote Action APIs and NQL queries to execute these tasks. Since both Moveworks and Spark AI share these capabilities, the decision rests on whether you prefer a single assistant for all troubleshooting or multiple specialized assistants. Each approach has its pros and cons.

While Spark AI is more deeply integrated into Nexthink, Moveworks is fully capable of serving as a centralized hub for any use case requiring Remote Action APIs and NQL.

I’d love to implement a flow where a user asks for access to a shared network drive, and the bot pings Nexthink to check if they have access already--if they do, it checks if the user is on VPN, and then maps the drive for them. If they don’t, it helps them submit their request for access, then pings them once it is approved and maps the drive for them. I’d love any thoughts on how to achieve this!

​@Danielle.K this type of use case would be done using Remote Actions API and NQL. After doing some discovery, I believe the below would be the high-level steps and Actions to use. For this use case, there is some branching logic as seen below that you would want to incorporate using Switch statements in Agent Studio:

Here is the outline of the specific APIs and Remote Actions that would be relevant (can differe per tenant):

1. Check Drive Access
Since drive access is typically governed by Active Directory (AD) or Entra ID groups, you have two main options:

• Nexthink Flow - Entra ID Connector: Use the Check if a user is in a group thinklet. This is a low-code way to ping your identity provider directly via Nexthink to verify membership in the specific security group for that drive.
• NQL API: If you sync your AD groups into Nexthink as "User Tags" or "Custom Fields," you can run a simple NQL query to check membership:
  • users | where name == "insert_username_here" | compute groups

2. Check VPN Access
The next step is ensuring the user is on the VPN.

• Remote Action: "Get Network Connections" (Library Pack): Nexthink has a pre-built Remote Action in the Network Management library pack. You can trigger this via API to return the current interface type (Ethernet, Wi-Fi, or VPN).
• Custom NQL Check: You can check the device.network_interfaces table via the NQL API to see if a virtual adapter (VPN) is currently up.

3. Mapping the Drive
Once access and VPN are confirmed, you trigger the "heavy lifting" script.

• Remote Action: "Map Network Drive" (Library Pack): Nexthink provides a standard "Map Network Drive" Remote Action.
  • Parameters needed: Drive, Network Path, and Maximum Delay In Seconds.
  • API Trigger: You would call the Remote Actions API using the POST /remoteactions/{id}/executions endpoint, passing the user’s device_id and the drive parameters.

This is just an outline of the use case after doing some discovery, feel free to deviate from this, but this should help to get you off the ground!

Best,

Ryan

This is great! Thanks so much, Ryan!