Orchestrating Common Use Cases

Learn about recommended orchestration techniques for several common use cases.

In This Article

Glossary

There are a number of key terms relevant to the use cases described in this document.

Use Case #1: Custom Data Retrieval

Problem

As an analyst, I want to know which users have completed a particular Scenario so that I can issue credit to the users relating to the associated learning module in my system-of-record.

Solution

I will use a GraphQL client to retrieve Scenario Session data from the Scope GraphQL API which is not otherwise available in the Scope CMS user interface.

Procedure

1. The GraphiQL client application is installed and configured to communicate with the Scope GraphQL API (see “Exploring the Graph”)

2. The following query is executed:

   query {
     node(id: "INSERT_ID_OF_SCENARIO") {
       ... on Scenario {
         sessions {
           nodes {
             id
             state
             user {
               id
               name
             }
           }
         }
       }
     }
   }

3. The JSON response is reformatted to CSV (using any relevant tool) for merge with system-of-record data and/or reporting.

Use Case #2: Data Analytics

Problem

As an analyst, I want to import data from the Scope platform on a regular basis so I can visualize the data with my internal BI tools.

Solution

I will use a custom internal application and the Scope GraphL API to retrieve Scenario Session data and store in a Data Store that my BI tools can read.

Procedure

Customer creates a custom application that:

• Queries the Scope GraphL API on a regular basis.

• Translates the JSON response into a Schema most compatible with customer’s needs.

• Stores the translated data to customer’s Data Stores.

Use Case #3: Real-Time Integration with System-Of-Record

Problem

As an administrator, I want to associate Scope Scenario Session data with work orders in my system-of-record (e.g. Salesforce), in real-time, as my users interact with the Scope platform.

Solution

I will use a custom internal application, Deeplinks, Scenario Catalogs, Webhooks, and the Scope GraphL API to retrieve Scenario Session data, as the data becomes available, and associate said data with work orders in my system-of-record.

Orchestration Summary

• The system-of-record provides a work order identifier to the Scope platform whenever a user leaves the system-of-record to interact with the Scope platform.

• The Scope platform then attaches said work order identifier to the Scenario Session data that it creates and manages.

• The Scope platform then notifies a custom application (aka “Webhook Listener”), in real time, as the user creates and updates Scenario Session data.

• The Webhook Listener then retrieves Scenario Session data and stores in the system-of-record using the previously provided work order identifier to locate the relevant work order.

Configuration

1. For each physical device (aka the “Asset”) that work orders might pertain to in the system-of-record (.e.g. “Generator Model #1234”):

   1. The administrator creates at least one Scenario for the Asset using the Scope Create 2 application.

   2. The administrator creates a Scenario Catalog using the Scope CMS web interface.

2. The administrator configures the system-of-record to present a dynamically generated link whenever system-of-record users view work orders (aka the “Deeplink”). The link passes both the asset identifier and work order identifier as parameters:

   worklink://resource?action=fetch_catalog&asset=INSERT_ASSET_ID_HERE&work_order_id=INSERT_WORK_ORDER_ID_HERE

3. The administrator creates a custom internal application designed to receive Scope Webhooks, and configures the customer’s Scope account to send Webhooks to said application.

Procedure

1. The user visits the dynamic Deeplink preconfigured in the system-of-record.

2. The WorkLink app launches and loads the Scenario Catalog identified by the Deeplink asset_id query param.

3. The user selects a Scenario and begins a Scenario Session (causing all additional query parameters passed by the Deeplink to be stored as a JSON hash in the ScenarioSession.externalData attribute, including and especially the work_order_id).

4. The customer’s custom application receives Webhook event notifications and decides to act based on the event and data.resource_type payload values (i.e. when event = create or update, and resource_type = ScenarioSession).

5. The customer’s custom application queries the Scope GraphQL API and retrieves the data identified by the Webhook payload resource_id (see Sample Queries).

6. The customer’s custom application inspects the data retrieved for the value of ScenarioSession.externalData.work_order_id

7. The customer’s custom application then associates the retrieved Scenario Session data with the work order in the customer’s system-of-record (using system-of-record APIs).

Use Case #4: Call Integration (Coming Soon)

As a field service technician, I want an easy way to launch a call from our service desk application so that it’s associated with the active job id.

As an analyst, I want to measure time-to-resolution metrics for jobs that had AR Remote Assistance calls to measure ROI.

Application

• Simplified calling

• Closed loop service desk SLA metrics.

Orchestration

1. Users are assigned call IDs that can be integrated with a system-of-record (like a service desk tool’s contact list)

2. Experts can click on a Deeplink to launch application and call a specific contact from the system or record.