1. Help Center
  2. Automate workflow

Deep linking improves your workflow

Move seamlessly between DevicePilot and other applications, without losing context

You probably use several different applications alongside DevicePilot, for customer support, ticketing, billing and even your own custom applications. If all these applications are modern SaaS tools then it's often possible to create automatic hyperlinks so that with 1 click you can move from one application to another without losing your context. The "context" might be the device you're investigating, the customer you're serving, or the customer site you're analysing.

Let's imagine you are a provider of coffee machines and you use:

  • DevicePilot to monitor your devices and service delivery
  • Zendesk as your customer helpdesk application

Linking out from DevicePilot

On a DevicePilot dashboard you notice a reduction in service performance for a particular customer, and with a couple of clicks you drill-down to the specific coffee machine causing the problem. After exploring the history of that machine you decide that you need to contact the customer to ask them to clean a filter. DevicePilot may know something about that customer (at least, it knows the devices, and quite likely the customer name too, in order to calculate e.g. KPIs-by-customer). But manually looking-up that information in DevicePilot and then typing it in to Zendesk is a bit of a pain.

You can avoid this hassle forever by setting-up deep linking, to enable you to move between applications in a single click. In DevicePilot it is possible to construct a property on each device (called e.g. "Zendesk link") which has a value something like:

"https://company.zendesk.com/agent/search/1?q=requester%3Acustomer%40domain.com"

[The exact syntax depends on the service you're linking to, and the kind of query you need to run on it - you can often spot the required pattern by just using the other service and noticing what it says in the URL bar as you navigate. The strange %3A characters are URL encoding.]

For this to work, DevicePilot must know a "key" for each device that it can use to construct a URL that the other service will understand:

  • This key may be something that inherently makes sense to DevicePilot, such as the device ID $id, in which case each record in the other service needs to have a "device" property attached to it with this value, on which the URL will search
  • Alternatively the key is something that makes sense to the other service, such as the Customer id for a helpdesk application like Zendesk. 

Creating link properties

If you're pushing device metadata into DevicePilot from elsewhere, e.g. from a nightly cron job on a database, then you can make your job construct link properties dynamically as it pushes-in the rest of the metadata.

An easier and better solution is to get DevicePilot to construct a link property itself, dynamically for each devices, using a Calculated Property.

Using link properties

Whenever DevicePilot displays a property value, if that value is a string starting with "http" then it will automatically be turned into a hyperlink, which you can then click to jump to the other service. This works:

  1. On the View page in the Device List (just choose that property as one of the columns)
  2. On the View page in the Device Details widget
  3. On the Dashboard for any Device List

Deep links are also emitted by DevicePilot Rules notifications, and since the tool you use to receive those notifications (e.g. Email or Slack) will probably automatically turn them into hyperlinks for you, that becomes a 1-click solution. As well as the default link sent by the rule (which takes you into the right context within DevicePilot), you could also make the Rule emit deep links to other services too, as above (to explore how to parameterise notifications, click the '+' top right in the message box).  

Linking in to DevicePilot

You can also link back from another service into DevicePilot in the same way.

Imagine a coffee machine customer phones-up to say that their machine is broken. The first place to log that will be in Zendesk, but next you'll want to use DevicePilot to see the history and state of that machine, so you can diagnose and take action.

Exactly how to create a deep link from the other service into DevicePilot depends on the other service, but you can see the URL that you need to create by inspecting the URL bar while using DevicePilot (especially when you drill-down from one page to the next, because then DevicePilot is effectively deep linking to itself). For example:

  • Go to the DevicePilot View page and select a specific device:
    https://app.devicepilot.com/#/view?selectedId=1234
  • Go to the Devicepilot Cohort page and show a specific KPI:
    https://app.devicepilot.com/#/cohort/1234
  • Open a specific DevicePilot Dashboard:
    https://app.devicepilot.com/#/dashboard?dashboard=1234

Conclusion

Using multiple SaaS applications together allows each to focus on being really good at just one job, and also keeps confidential information confined within the application that needs it. Deep-linking using a common "key" makes it possible to move seamlessly between DevicePilot and other services with losing context, whilst analysing, fault-finding or serving a customer.