Integrated Monitoring from BPM
When Services in your BPM are linked to one or more Resources, Nodinite displays real-time monitoring status in both the BPM Designer and grouped Log Views. The familiar lightbulb icon shows the accumulated worst-case state across all linked Resources—giving you instant operational visibility without leaving the process context.
All the power of Monitor Views within your BPM:
- Visual status indicators - Lightbulb icon shows worst-case Resource state in Designer and Log Views
- Remote Actions - Start, Stop, Enable, Disable services directly from the BPM
- Knowledge Base Articles - Instant access to operator instructions and troubleshooting guides
- Custom Metadata - Organization-specific properties for fine-grained control across hundreds of processes
- Statistics and history - Same monitoring insights available in Monitor Views
- Role-based access - Self-service monitoring for business and technical users
Tip
Business users prefer business context? BPMs provide the same monitoring capabilities as Monitor Views, but organized by business process instead of technical hierarchy. Same features, business-friendly presentation.
Order-to-Cash BPM example showing Services (rounded rectangles) with monitoring status indicators. One or more Resources linked with Services enable the lightbulb monitoring display.
How Service Monitoring Works in BPM
1. Link Services to Resources
In the BPM Designer, you place Services in cells (Domain row × Step column). Each Service can be linked to one or more Resources:
Example
- Service: "Order Receiver" (in Sales Domain, Step 1)
- Linked Resources:
- Azure Service Bus Queue
orders-inbound-prod - BizTalk Receive Location
OrderReceivePort - File System Directory
\\fileserver\orders\incoming
- Azure Service Bus Queue
2. Lightbulb Icon Shows Worst-Case State
When Services have linked Resources, the lightbulb icon appears in:
- BPM Designer - Next to Service name in the cell
- Grouped Log View - Next to Service name in the milestone column
The lightbulb displays the accumulated "worst" state across all linked Resources:
| Lightbulb Color | Meaning | Example Scenario |
|---|---|---|
| Green | All Resources OK | All queues, services, and endpoints running normally |
| Yellow | One or more Resources in Warning state | Queue depth approaching threshold but not critical |
| Red | One or more Resources in Error state | BizTalk Receive Location stopped or Service Bus throttled |
| Gray | Resources Unavailable or no recent data | Monitoring Agent not reporting or Resource disabled |
Clicking the lightbulb opens a panel showing:
- All linked Resources with individual states
- Available Remote Actions for each Resource
- Links to Knowledge Base Articles for troubleshooting
- Custom Metadata fields (Owner, SLA, Escalation Contact, etc.)
3. Perform Remote Actions from BPM
Just like Monitor Views, you can trigger Remote Actions directly from the BPM:
Common Actions
- Start/Stop - BizTalk Receive Locations, Send Ports, Orchestrations, Host Instances
- Enable/Disable - Azure Logic Apps, Service Bus Queues
- Restart - Windows Services, Azure Function Apps
- Purge Queue - Service Bus, MSMQ
- Custom actions - Organization-specific operations
Example Workflow
- User opens grouped Log View for Order-to-Cash process
- Sees red lightbulb next to "Confirmation Sent" Service
- Clicks lightbulb → Shows "ConfirmationEmailQueue" Resource in Error state
- Clicks "Restart" → Nodinite restarts the service via Monitoring Agent
- Lightbulb turns green, process resumes
No infrastructure access required - Users perform operations through Nodinite without RDP, VPN, or Azure Portal credentials.
4. Access Knowledge Base Articles
When troubleshooting, click the lightbulb to access Knowledge Base Articles linked to Services or Resources:
Article Types
- Operator instructions - Step-by-step recovery procedures
- Troubleshooting guides - Common errors and resolutions
- Escalation procedures - When to contact support, who to escalate to
- SLA documentation - Expected response times, business impact
- Change logs - Recent configuration changes, deployment notes
Example Article: Order Receiver Queue Full
- Check queue depth:
Get-AzServiceBusQueue -ResourceGroupName prod -NamespaceName orders-ns -Name orders-inbound-prod - Verify downstream service health (Order Entry service)
- If downstream is healthy, increase throughput or purge invalid messages
- If downstream is stopped, restart via Remote Actions
- Escalate to Platform Team if issue persists >15 minutes (SLA: P1)
Articles are context-sensitive - shown only for the Service/Resource you're troubleshooting.
5. Leverage Custom Metadata for Fine-Grained Control
With hundreds of processes, Custom Metadata provides organization-specific attributes for Services, Resources, and entire BPMs:
Common Custom Metadata Fields
| Field Name | Purpose | Example Value |
|---|---|---|
| Owner | Process/service owner | "John Smith (Finance Team)" |
| Team | Responsible team | "Integration Platform Team" |
| BusinessContact | Business stakeholder | "Jane Doe (Sales Ops Manager)" |
| SLA | Service level agreement | "99.5% uptime, <15 min MTTR" |
| EscalationPath | Who to contact | "Team Lead → Manager → Director" |
| CostCenter | Billing department | "CC-12345 (Sales Division)" |
| Criticality | Business importance | "P1 - Revenue impacting" |
| MaintenanceWindow | Allowed downtime | "Sundays 2-6 AM UTC" |
| ComplianceTag | Regulatory requirements | "GDPR, SOX, PCI-DSS" |
| DeploymentGroup | Release cadence | "Monthly Patch Cycle" |
Benefits
- Search and filter - Find all P1 services owned by Finance Team
- Bulk operations - Update SLA for all services in Production domain
- Reporting - Generate compliance reports by ComplianceTag
- Access control - Grant permissions based on Owner or Team metadata
- Escalation automation - Auto-notify EscalationPath contacts on repeated failures
Example Use Case: 200 BPMs Across Organization
Instead of searching through diagrams, filter by:
Owner: "Integration Team"- Show 45 BPMs owned by Integration TeamCriticality: "P1"- Show 12 revenue-critical processes requiring 24/7 monitoringComplianceTag CONTAINS "SOX"- Show 8 processes requiring Sarbanes-Oxley audit trails
Custom Metadata makes managing hundreds of processes practical and scalable.
Monitoring in BPM Designer vs. Grouped Log View
Both views display the lightbulb indicator, but with different contexts:
BPM Designer View
When to Use
Process design, documentation, high-level health overview
What You See
- All Services in swimlane diagram (Domain rows × Step columns)
- Lightbulb icon next to each Service linked to Resources
- Real-time accumulated state (worst-case across linked Resources)
- Click lightbulb → Resource details panel with Remote Actions
Best For
- Architects designing new processes
- Operations teams troubleshooting failed steps
- Business stakeholders checking overall process health
Grouped Log View
When to Use
Troubleshooting specific transactions, drilling into log events
What You See
- Milestone-based log events for a specific transaction (Order ID, Invoice Number, etc.)
- Services shown as milestones with timestamps
- Lightbulb icon next to Service milestones
- Click lightbulb → Resource status + Remote Actions + Knowledge Base Articles
- Log events below each milestone showing detailed execution history
Best For
- Support teams investigating why Order #12345 failed at Step 3
- Compliance audits requiring full transaction history
- Root-cause analysis for specific incidents
Both views provide identical monitoring capabilities - choose based on whether you need process-wide overview (Designer) or transaction-specific detail (Log View).
Complete Feature Parity with Monitor Views
Everything you can do in a Monitor View, you can do from BPM:
| Feature | Monitor View | BPM Designer | Grouped Log View |
|---|---|---|---|
| View Resource status | ✅ | ✅ (via lightbulb) | ✅ (via lightbulb) |
| Perform Remote Actions | ✅ | ✅ | ✅ |
| Access Knowledge Base Articles | ✅ | ✅ | ✅ |
| View Custom Metadata | ✅ | ✅ | ✅ |
| See monitoring statistics | ✅ | ✅ | ✅ |
| Configure alerts | ✅ | ✅ (inherited) | ✅ (inherited) |
| Role-based security | ✅ | ✅ | ✅ |
| Auto-healing | ✅ | ✅ (inherited) | ✅ (inherited) |
The difference: Monitor Views organize by technical hierarchy (Applications, Categories, Resources). BPMs organize by business process (Domains, Steps, Services). Same operational capabilities, different organizational lens.
Prerequisites
Important
To enable monitoring in BPM:
- Monitoring Agents - Install and configure agents for your platforms (BizTalk, Azure, databases, file systems)
- Resources - Resources are automatically created by Monitoring Agents when they discover monitorable entities (queues, services, endpoints, etc.). The Nodinite Administrator must then include them in Monitor Views and/or assign Resources to Services
- Services - Create Services in Repository Model
- Link Services to Resources - In BPM Designer, assign Resources to each Service
- Monitor Views (optional) - BPM monitoring works independently, but Monitor Views provide additional dashboards
Without linked Resources, Services will not show the lightbulb indicator.
Best Practices
Link All Services to Resources
✅ Do link Services to monitoring Resources - Enables lightbulb status in BPM Designer and Log Views
✅ Link multiple Resources per Service - Shows worst-case state (most critical issue bubbles up)
❌ Don't leave Services unmonitored - Users won't have operational visibility or Remote Actions
Use Custom Metadata for Organization-Specific Attributes
✅ Define Owner field - Know who to contact when Service fails
✅ Define SLA field - Document expected uptime and response times
✅ Define EscalationPath field - Automate escalation workflows
✅ Tag with Criticality - Prioritize P1 services in dashboards and alerts
❌ Don't rely on memory - Hundreds of processes require documented Custom Metadata
Combine BPM and Monitor Views
✅ BPM for business stakeholders - Process-oriented view with business context
✅ Monitor Views for operations teams - Technical hierarchy view with same Resources
✅ Both - Different audiences, same underlying monitoring data
Example
- BPM: "Order-to-Cash Process" - Business stakeholders see all 7 steps with lightbulb status
- Monitor View: "Production Azure Resources" - Ops team sees all Azure Resources across all BPMs
Both access the same "Order Receiver Queue" Resource with identical Remote Actions and Knowledge Base Articles.
Document Troubleshooting in Knowledge Base Articles
✅ Write operator instructions - Empower front-line support to resolve issues
✅ Include escalation procedures - When to escalate, who to contact
✅ Link to Services AND Resources - Articles shown in both BPM and Monitor View contexts
❌ Don't rely on tribal knowledge - Staff turnover causes lost expertise
Next Steps
What is the BPM Designer - Create BPMs with Services and monitoring
Services - Define Services and link to Resources
Resources - Set up monitored Resources
Remote Actions - Configure available actions
Knowledge Base Articles - Write troubleshooting guides
Custom Metadata - Add organization-specific fields
Related Topics
Monitor Views - Technical-hierarchy monitoring view
Business Process Model (BPM) - Complete BPM overview
End-to-End Process Tracking - Correlate log events across systems
Roles - Role-based access control
Alarm Plugins - Alert configuration (inherited by BPMs)