01Business KPIs — Last 12 Months
02Use Cases & Playbook Distribution
Cumulative Playbooks Built — Last 90 Days
New Active Workflows Added — Last 30 Days
| Use Case | Key Business KPIs | Share of Activity | Playbooks |
|---|---|---|---|
| Use Case 1 — Windows Service Auto-Recovery & Diagnostics | 1,052 executions | 14.8% | 30 30 active |
| Use Case 2 — Vertica Database Cluster Monitoring & Recovery | 0 executions | 0.0% | 7 7 active |
| Use Case 3 — HashiCorp Vault Auto-Unsealing |
| 0.1% | 2 1 active |
| Use Case 4 — Managed Service Platform Administration | 0 executions | 0.0% | 7 7 active |
| Use Case 5 — Dev/Test Environment Startup & Shutdown Orchestration | 0 executions | 0.0% | 9 9 active |
| Total | 1,057 executions | 100% | 55 54 active |
Use Case Growth Over Time
03Integration Ecosystem
LogicMonitor
SSH
AWS
ServiceNow LogicMonitor ServiceNow
Microsoft Teams AWS ServiceNow LogicMonitor
Microsoft SQL Server SSH AWS04Key Observations
Strengths
Deep WinRM automation maturity. The Windows service recovery suite is one of the most complete endpoint remediation patterns seen in production Blink deployments. It covers the full loop: alert ingestion, deduplication, seven distinct diagnostic dimensions (CPU, memory, disk space, disk I/O, process-level CPU/memory, service PIDs), log collection, automated kill/restart, S3 upload, and SNOW case creation — all without a human in the loop.
Parallel POC and production environments. Emerson runs 6+ parallel POC workspaces alongside production, each containing full copies of the Windows recovery suite. The POC environments drove the bulk of execution volume (344 runs in workspace 9eecac28 alone vs. 2–4 in production), indicating an active validation and staging discipline before production promotion.
Race condition prevention built in. Both the Windows and Vertica orchestrators include explicit deduplication logic — checking for existing in-flight executions for the same target host before proceeding. This pattern prevents duplicate SNOW cases and conflicting WinRM operations, a level of operational sophistication uncommon at this stage of automation maturity.
Multi-datasource alert routing. The Logic Monitor Webhook Router handles 5 distinct datasource conditions (Vertica port, OptimalPlus CPU/Memory, OptimalPlus Services, HashiCorp Vault health) in a single event-driven automation, routing each to the appropriate workspace and workflow via Blink's own API. This positions the platform as a meta-orchestration layer above individual tools.
###
Gaps
Vertica and Vault automations have zero production executions. Both use cases are fully built and exist in production (workspace d8f9726d) but have never been triggered. This could indicate that LogicMonitor webhook routing to the Vertica/Vault conditions has not yet been connected to the production automation, or that the relevant alerts have not fired. Given the 28 production runs of the router (all apparently routing to Windows recovery), it is worth verifying that Vertica and Vault conditions are wired in the router's condition table.
No Vertica active remediation. The Vertica workflow suite diagnoses node status and file system health but does not attempt automated remediation (e.g., restarting the Vertica service, clearing disk space, or running a recovery command). The Windows suite has kill/restart logic; bringing Vertica to the same level would complete the use case.
Platform administration at zero. The workspace provisioning and customer registry playbooks (Create Customer Workspace, Add New Customer To List) show zero executions, suggesting this capability may be available but not yet adopted in practice, or that customer onboarding is still handled manually.
Environment startup/shutdown suite not yet exercised. The newly built dev/test environment health-check and shutdown subflows (Windows, SQL DB, Vertica DB, GlobalOps services, Linux mounts, EC2) all show zero executions. No top-level orchestrator or schedule triggering this suite is present in the data, suggesting the individual building blocks are complete but not yet wired into a scheduled or on-demand environment lifecycle workflow.
No security-focused use cases. Emerson's entire Blink footprint is IT/OT operations and infrastructure automation — there are no SOC, vulnerability management, IAM, or compliance use cases currently built. Given Emerson's industrial and critical infrastructure profile, there is a clear expansion opportunity in areas such as OT network anomaly detection, privileged access management for operational systems, or compliance reporting for ICS/SCADA environments.
Integration Ecosystem
| Integration | Used In |
|---|---|
| LogicMonitor | Alert source for all event-driven workflows |
| WinRM | Windows diagnostics and remediation (all 7 metric types + kill/start) |
| ServiceNow | Incident creation, commenting, and file attachment |
| AWS S3 | Log file upload via presigned URL |
| AWS EC2 | Instance stop/start control for dev/test environment lifecycle |
| SSH | Vertica cluster diagnosis, Linux filesystem checks, share remounting, and dev/test environment shutdown sequencing |
| MSSQL | SQL Server health checks and graceful shutdown queries |
| HashiCorp Vault (HTTP) | Vault seal status check and unseal |
| Blink (self-referencing) | Execution deduplication, workspace provisioning, rate limiting |
| Microsoft Teams | Error escalation notifications |
A Case Management
Case Management
No case management data found for this customer.
B AI Agents
AI Agents
No agent data found for this customer.
C Self-Service & Webforms 0 app runs | 0 form submissions
Self-Service Applications
No self-service usage data found for this customer.
Webforms
| # | Form | Total | Completed |
|---|---|---|---|
| 1 | Request Demo Env Details | 0 | 0 |
| 2 | Request For Demo Evn | 0 | 0 |
| 3 | Request Demo Env Details | 0 | 0 |
D Full Use Case Analysis 5 use cases | 7,088 executions (12m)
Business KPIs
| Metric | Count | Playbook |
|---|---|---|
| Windows service recovery operations executed | 289 | Windows Service Recovery (all workspaces) |
| Windows host diagnostics collected & posted to ServiceNow | 443 | Get Windows Metrics And Update SNOW (all workspaces) |
| ServiceNow incidents auto-created for Windows service failures | 271 | Creating SNOW Case - Windows (all workspaces) |
| Service log files captured from Windows hosts and uploaded to S3 | 146 | Windows - Upload File via Runner (all workspaces) |
| Infrastructure alerts automatically triaged and routed | 28 | Logic Monitor Webhook Router |
Use Case Summary
| # | Use Case | Category | Playbook Types | Executions (12 mo) |
|---|---|---|---|---|
| 1 | Windows Service Auto-Recovery & Diagnostics | Other | 16 | 1,177 |
| 2 | Vertica Database Cluster Monitoring & Recovery | Other | 7 | 0 |
| 3 | HashiCorp Vault Auto-Unsealing | IAM | 1 | 0 |
| 4 | Managed Service Platform Administration | Other | 7 | 0 |
| 5 | Dev/Test Environment Startup & Shutdown Orchestration | Other | 9 | 0 |
_Playbook types are counted as unique logical automations; each type may exist across multiple workspaces (production + POC environments). Execution totals aggregate across all workspace instances._
Use Cases
Use Case 1 — Windows Service Auto-Recovery & Diagnostics
Category: Other
Subcategories: IT/OT & network infra monitoring · Endpoint hygiene & MDM ops
Description:
When LogicMonitor detects a critical Windows service event — such as a service down, CPU/memory spike, or OptimalPlus service anomaly — a webhook fires to the Blink router, which identifies the target workspace and dispatches the recovery workflow. The recovery orchestrator checks for concurrent runs on the same host to prevent race conditions, then gathers a full diagnostic snapshot (CPU, memory, disk I/O, process-level metrics), collects the service log file and uploads it to S3, kills and restarts the hung service, creates a ServiceNow incident with the full diagnostic context, and escalates to a human operator if automatic recovery fails.
Business problem solved:
Critical Windows services supporting OT and analytics infrastructure require near-instant response when they degrade. Manual operator paging, SSH login, and diagnostic collection takes 15–30 minutes; this automation completes the full diagnose-remediate-document cycle in under 2 minutes and creates a traceable ServiceNow record regardless of outcome.
Integrations: LogicMonitor · WinRM · ServiceNow · AWS S3 · Blink (execution control / self-referencing)
Playbooks — Production (workspace d8f9726d)
| Playbook | Executions | Role |
|---|---|---|
| Logic Monitor Webhook Router | 28 | Event-driven entry point — routes LogicMonitor webhooks (Vertica, Windows, Vault datasources) to the correct workspace and automation |
| Windows Service Recovery | 2 | Primary orchestrator — deduplicates concurrent runs, calls diagnostics, kill/restart, SNOW case creation, and error escalation |
| Get Windows Metrics And Update SNOW | 4 | Aggregates all Windows metrics sub-flows and posts results as a ServiceNow incident comment |
| Windows - Get PIDs from Service Name | 4 | Retrieves parent and child PIDs for a named Windows service via WinRM |
| Windows - Get CPU Utilization | 4 | Collects host-level CPU utilization percentage via WinRM |
| Windows - Get CPU Utilization of PID | 4 | Collects CPU utilization for a specific process ID via WinRM |
| Windows - Get Memory Utilization | 4 | Collects host-level memory utilization percentage via WinRM |
| Windows - Get Memory Usage of PID | 4 | Collects memory usage (MB) for a specific process ID via WinRM |
| Windows - Get Disk Space Utilization | 4 | Collects disk space utilization percentage via WinRM |
| Windows - Get Disk Read and Write Utilization | 4 | Collects disk I/O read/write utilization via WinRM |
| Windows - Get Log File Path | 2 | Resolves the log file path for a named Windows service via WinRM |
| Windows - Kill Service and Child PIDs | 2 | Terminates a service and all child processes via WinRM |
| Windows - Start Service | 2 | Starts a named Windows service and validates restart success via WinRM |
| Windows - Upload File via Runner | 0 | Compresses and base64-encodes a log file on the Windows host, generates an S3 presigned URL, and uploads via PowerShell |
| Creating SNOW Case - Windows | 2 | Creates a ServiceNow incident with conditional deduplication; outputs sys_id and case number |
| Error Handling | 0 | Generates structured error messages and prints to logs |
Playbooks — POC (primary POC workspace 9eecac28)
_Additional POC instances exist across workspaces 0a7de9f6 (85 service recovery executions), 213d0a08 (6), and 5920c012 (6)._
Use Case 2 — Vertica Database Cluster Monitoring & Recovery
Category: Other
Subcategories: IT/OT & network infra monitoring
Description:
When LogicMonitor fires an alert matching Vertica-specific datasources (Vertica port listening, OptimalPlus Service CPU/Memory, OptimalPlus Services), the Webhook Router dispatches the Vertica Handle DB Alert workflow. This orchestrator checks for concurrent runs on the same host, then coordinates a full cluster health assessment: retrieving node status via SSH, pinging all private IPs to confirm network reachability, checking file system utilization across all cluster nodes, and creating a ServiceNow incident with the diagnostic results. A ServiceNow comment and file attachment workflow captures additional evidence.
Business problem solved:
Vertica database outages directly impact analytics and operational reporting. Cluster-level diagnosis normally requires database administrator involvement and SSH expertise; this automation produces a complete node health picture in seconds, routes it directly into ServiceNow, and frees the DBA to focus on root cause rather than data collection.
Integrations: LogicMonitor · SSH · ServiceNow
Playbooks
| Playbook | Executions | Role |
|---|---|---|
| Logic Monitor Webhook Router | 28 | Shared entry point — routes Vertica datasource events alongside Windows alerts |
| Vertica Handle DB Alert | 0 | Primary Vertica orchestrator — deduplicates concurrent runs, calls status check, file system check, node ping, SNOW case creation |
| Vertica Get Nodes Status | 0 | Queries Vertica node table via SSH, parses status, returns active node and per-node IPs and states |
| Linux Get filesystems | 0 | Retrieves filesystem utilization data per node via SSH |
| Vertica Check Servers File Systems | 0 | Iterates over cluster IPs, calls Linux Get filesystems per node, aggregates status |
| Vertica Ping Nodes and Report to Service Now | 0 | Pings all cluster private IPs via SSH from active node; reports inaccessible nodes to ServiceNow |
| Creating SNOW Case | 0 | Creates a ServiceNow record for Vertica incidents |
| ServiceNow Case - create comment and upload file | 0 | Adds a comment to a ServiceNow record and attaches an evidence file |
_POC variants (Vertica Handle DB Alert (POC), Vertica Get Nodes Status (POC), etc.) exist in workspaces 9eecac28, 213d0a08, c881d3da, 5920c012, 604af23a, and 0a7de9f6, all with 0 executions._
Use Case 3 — HashiCorp Vault Auto-Unsealing
Category: IAM
Subcategories: Privileged account mgmt · IT/OT & network infra monitoring
Description:
When LogicMonitor detects the HashiCorp_Vault_Health datasource alert, the Webhook Router dispatches the Unseal Vault workflow. The automation first checks for concurrent unseal attempts (deduplication via Blink execution history), then queries the Vault HTTP API to verify the seal status — skipping execution if Vault is already unsealed. If sealed, it proceeds through a structured try/catch block to execute the unseal sequence, with error escalation to ServiceNow on failure.
Business problem solved:
Vault sealing after node restarts or network partitions blocks all secrets-dependent services across the organization. Manual unsealing requires on-call pager response, secure access to Vault nodes, and precise key entry — typically a 10–20 minute process. Automation eliminates the human response loop for routine seals.
Integrations: LogicMonitor · HashiCorp Vault (HTTP API) · Blink (execution deduplication)
Playbooks
| Playbook | Executions | Role |
|---|---|---|
| Logic Monitor Webhook Router | 28 | Shared entry point — routes HashiCorp_Vault_Health events alongside other datasource alerts |
| Unseal Vault | 0 | Checks current seal status, deduplicates concurrent attempts, executes unseal with try/catch error handling |
Use Case 4 — Managed Service Platform Administration
Category: Other
Subcategories: SaaS / IT administration · Customer registry & FinOps auto
Description:
Emerson uses Blink to automate the lifecycle of its managed service customer workspaces — from provisioning new workspaces and registering customers in a global list, to controlling automation execution thresholds that prevent runaway workflows. These playbooks manage the Blink platform itself: creating workspaces via the Blink API, adding admin groups, and enforcing execution deduplication and rate controls.
Business problem solved:
Manually provisioning customer workspaces in a multi-tenant managed service requires consistent configuration steps that are easy to misconfigure. Automation ensures every workspace is provisioned identically, admin groups are always added, and no single automation can flood the platform with duplicate runs.
Integrations: Blink (admin API) · Microsoft Teams
Playbooks
| Playbook | Executions | Role |
|---|---|---|
| Create Customer Workspace | 0 | Checks for existing workspaces, creates new workspace via Blink API, adds admin group; used in production managed service operations |
| WS Creation | 0 | Alternate workspace creation flow; same logic with different Blink connection |
| Add New Customer To List | 0 | Retrieves global customer list variable, checks for duplicates, appends new customer, updates global variable |
| Is Already Running | 0 | Checks whether a given automation is currently executing in a given workspace; returns boolean result |
| Execution Threshold Control | 0 | Rate-limits an automation by tracking executions in a Blink table; blocks new runs if threshold is exceeded within a time window |
| Unblock Automation | 0 | Removes the rate-limit block record from the Blink table, restoring execution eligibility |
| Return Status | 0 | Utility subflow that standardizes pass/fail status returns across use cases |
Use Case 5 — Dev/Test Environment Startup & Shutdown Orchestration
Category: Other
Subcategories: DevOps & release automation · IT/OT & network infra monitoring
Description:
A modular suite of subflows that health-checks and gracefully shuts down the components of Emerson's t2_dev environment — Windows servers, a Microsoft SQL Server database, a Vertica database cluster, GlobalOps services, Linux file mounts, and EC2 compute. Each subflow handles one component type: polling-based health checks with configurable retry windows (GlobalOps services, Linux mounts), direct status checks (Windows servers, SQL DB, Vertica DB), and shutdown sequences that close active sessions before stopping the service and verifying the stop completed (SQL DB, Vertica DB, EC2). A companion subflow remounts a network share on a target host via SSH.
Business problem solved:
Non-production environments accrue infrastructure cost when left running and require coordinated, multi-system verification (database session closure, node status, mount health, instance state polling) to shut down and restart safely. This suite standardizes that sequencing across Windows, SQL Server, Vertica, and EC2 so environment lifecycle operations no longer depend on manual DBA/sysadmin sign-off at each step.
Integrations: AWS EC2 · MSSQL · SSH · Windows (server health enumeration)
Playbooks (workspace d8f9726d)
| Playbook | Executions | Role |
|---|---|---|
| Health Check - Windows Servers - Subflow | 0 | Loops over a list of Windows servers and returns any that fail their health check |
| Health Check - SQL DB - Subflow | 0 | Runs an MSSQL query to check database health and returns step status and query result |
| Health Check - Vertica DB - Subflow | 0 | Starts a Vertica DB node via SSH, checks cluster node status, and extracts any nodes not UP |
| Health Check - GlobalOps Services - Subflow | 0 | Polls GlobalOps services on a host in a bounded retry loop and returns any still in a bad state |
| Remount Share - Subflow | 0 | Remounts a network share on a target host via SSH |
| Health Check - Linux Mount and Verify - Subflow | 0 | Polls Linux file system mounts on a host in a bounded retry loop and returns any that failed to come back up |
| Stop EC2 Server - Subflow | 0 | Stops an EC2 instance via the AWS API and polls instance state until confirmed stopped |
| Shutdown - SQL DB - Subflow | 0 | Runs a graceful MSSQL shutdown query and polls database status until confirmed down |
| Shutdown - Vertica DB - Subflow | 0 | Closes active Vertica sessions via SSH, stops the Vertica DB, and verifies all nodes report DOWN |
Key Observations
Strengths
Deep WinRM automation maturity. The Windows service recovery suite is one of the most complete endpoint remediation patterns seen in production Blink deployments. It covers the full loop: alert ingestion, deduplication, seven distinct diagnostic dimensions (CPU, memory, disk space, disk I/O, process-level CPU/memory, service PIDs), log collection, automated kill/restart, S3 upload, and SNOW case creation — all without a human in the loop.
Parallel POC and production environments. Emerson runs 6+ parallel POC workspaces alongside production, each containing full copies of the Windows recovery suite. The POC environments drove the bulk of execution volume (344 runs in workspace 9eecac28 alone vs. 2–4 in production), indicating an active validation and staging discipline before production promotion.
Race condition prevention built in. Both the Windows and Vertica orchestrators include explicit deduplication logic — checking for existing in-flight executions for the same target host before proceeding. This pattern prevents duplicate SNOW cases and conflicting WinRM operations, a level of operational sophistication uncommon at this stage of automation maturity.
Multi-datasource alert routing. The Logic Monitor Webhook Router handles 5 distinct datasource conditions (Vertica port, OptimalPlus CPU/Memory, OptimalPlus Services, HashiCorp Vault health) in a single event-driven automation, routing each to the appropriate workspace and workflow via Blink's own API. This positions the platform as a meta-orchestration layer above individual tools.
Gaps
Vertica and Vault automations have zero production executions. Both use cases are fully built and exist in production (workspace d8f9726d) but have never been triggered. This could indicate that LogicMonitor webhook routing to the Vertica/Vault conditions has not yet been connected to the production automation, or that the relevant alerts have not fired. Given the 28 production runs of the router (all apparently routing to Windows recovery), it is worth verifying that Vertica and Vault conditions are wired in the router's condition table.
No Vertica active remediation. The Vertica workflow suite diagnoses node status and file system health but does not attempt automated remediation (e.g., restarting the Vertica service, clearing disk space, or running a recovery command). The Windows suite has kill/restart logic; bringing Vertica to the same level would complete the use case.
Platform administration at zero. The workspace provisioning and customer registry playbooks (Create Customer Workspace, Add New Customer To List) show zero executions, suggesting this capability may be available but not yet adopted in practice, or that customer onboarding is still handled manually.
Environment startup/shutdown suite not yet exercised. The newly built dev/test environment health-check and shutdown subflows (Windows, SQL DB, Vertica DB, GlobalOps services, Linux mounts, EC2) all show zero executions. No top-level orchestrator or schedule triggering this suite is present in the data, suggesting the individual building blocks are complete but not yet wired into a scheduled or on-demand environment lifecycle workflow.
No security-focused use cases. Emerson's entire Blink footprint is IT/OT operations and infrastructure automation — there are no SOC, vulnerability management, IAM, or compliance use cases currently built. Given Emerson's industrial and critical infrastructure profile, there is a clear expansion opportunity in areas such as OT network anomaly detection, privileged access management for operational systems, or compliance reporting for ICS/SCADA environments.
Integration Ecosystem
| Integration | Used In |
|---|---|
| LogicMonitor | Alert source for all event-driven workflows |
| WinRM | Windows diagnostics and remediation (all 7 metric types + kill/start) |
| ServiceNow | Incident creation, commenting, and file attachment |
| AWS S3 | Log file upload via presigned URL |
| AWS EC2 | Instance stop/start control for dev/test environment lifecycle |
| SSH | Vertica cluster diagnosis, Linux filesystem checks, share remounting, and dev/test environment shutdown sequencing |
| MSSQL | SQL Server health checks and graceful shutdown queries |
| HashiCorp Vault (HTTP) | Vault seal status check and unseal |
| Blink (self-referencing) | Execution deduplication, workspace provisioning, rate limiting |
| Microsoft Teams | Error escalation notifications |
E New Integrations (detail) 11 added in last 30d
New Integrations Added - Last 30 Days
| Tenant | Integration | Connection Name | Added |
|---|---|---|---|
| Emerson | winrm | winrm_demo | 2026-08-28 |
| Emerson | winrm | winrm_demo | 2026-08-28 |
| Emerson | ssh | ssh_dbadmin_demo | 2026-08-28 |
| Emerson | ssh | ssh_dbadmin_demo | 2026-08-28 |
| Emerson | ssh | ssh_root_demo | 2026-08-28 |
| Emerson | ssh | ssh_root_demo | 2026-08-28 |
| Emerson | mssql | microsoft_sql_demo | 2026-08-28 |
| Emerson | mssql | microsoft_sql_demo | 2026-08-28 |
| Emerson | aws | aws_demo | 2026-08-28 |
| Emerson | aws | aws_demo | 2026-08-28 |
| Emerson | ssh | ssh_connection_t2_dev_dbadmin | 2026-08-12 |