...
Key Term | Description |
|---|---|
GraphQL API | Method of retrieving a customer’s data via a single endpoint. For more information, please see “Introduction to the Scope GraphQL API”. |
DeepLinks | Method of launching the Scope Worklink app via a structure URL. For more information, please see “Using Deeplinks”. |
Webhooks | Method of notifying a customer’s internal systems about key events that take place in the Scope platform. For more information, please see “Using Webhooks”. |
Scenarios | Sets of work instructions pertaining to a specific physical device, to completed by a user while using the Scope Worklink app. For more information, please see “Scenario” in the reference docs. |
Scenario Sessions | Recordings of Scenarios performed and completed by a user while using the Scope Worklink app. For more information, please see “ScenarioSession” in the reference docs. |
Scenario Catalogs | Method of mapping a customer’s internal system objects (like assets or training modules) to Scenario Sessions. For more information, please see “ScenarioCatalog” in the reference docs. |
...
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.
To view a live demo of a “custom internal application”, complete with source code, see https://api-demo-ruby.scopear.com.
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 Scope Platform can accept and store any number of external data objects, not just work order identifiers. For more information , see “Using Deeplinks”.
Configuration
For each physical device (aka the “Asset”) that work orders might pertain to in the system-of-record (.e.g. “Generator Model #1234”):
The administrator creates at least one Scenario for the Asset using the Scope Create 2 application.
The administrator creates a Scenario Catalog using the Scope CMS web interface.
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:
Code Block worklink://resource?action=fetch_catalog&asset=INSERT_ASSET_ID_HERE&work_order_id=INSERT_WORK_ORDER_ID_HERE
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.
Scope Deeplinks are highly extensible and accept any number of external data parameters, not just work_order_id. For more information, see “Using Deeplinks”.
For sample example Salesforce Deeplink configuration instructions, please see “ServiceMax Configuration Guide”.
Procedure
...
The user visits the dynamic Deeplink preconfigured in a Deeplink dynamically generated by the system-of-record (see “configuration” above).
The WorkLink app launches and loads the Scenario Catalog identified by the Deeplink Deeplink’s
asset_idquery param.The user selects a Scenario and begins a Scenario Session (causing all additional query parameters passed by the Deeplink to be stored as key-value pairs in a JSON hash in on the
ScenarioSession.externalDataattribute, including and especially the notablywork_order_id).The customer’s custom application receives Webhook event notifications and decides to act based on the
eventanddata.resource_typepayload values (i.e. when event =createorupdate, and resource_type =ScenarioSession).from the Scope platform.The customer’s custom application queries the Scope GraphQL API and retrieves the to retrieve ScenarioSession data identified by the Webhook payload
resource_id(see Sample Queries).The customer’s custom application inspects the data retrieved for the value of
ScenarioSession.externalData.work_order_idThe 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, or similar).
The customer’s custom application receives ALL Webhook notifications, not just create and update events pertaining to ScenarioSessions. The application should inspect the Webhook’s payload event and data.resource_type values in order to determine the proper action to take.
Use Case #4: Call Integration (Coming Soon)
...