Observation works out of the box once enabled, but several aspects can be configured to match your organization's monitoring needs: the application-level on/off switch, custom conversation tags, custom dashboard widgets, and the underlying database.
Observation is enabled or disabled in the web menu configuration file - apps.json
{ "displayName": "Observation", "pathName": "observation" }The auto-tagging system produces a standard set of tags for every conversation (Topic, Sentiment, Resolution Status, Risk Level, Follow-up Required). These are stored in the INSIGHTS table in the Observation database.
The signals extracted from each conversation are defined in the chat_signals.csv MTable. Each row defines one signal with its name, allowed values, and whether multiple values can be assigned (multi-select).
Default signals include: Topic, Sentiment, Resolution Status, Urgency Level, Follow-up, Complaint Severity, Upsell Opportunity, and others. Edit the MTable in Fabric Studio to add, remove, or modify signals for your domain.
Dashboard widgets are defined in the widgets MTable in Fabric Studio. Each row in this table defines one widget that appears in the Observation dashboard.
box (KPI card)
Displays a single aggregated value. The action SQL query must return a single scalar (e.g., a count or percentage).
Example - count of unresolved conversations:
SELECT COUNT(*) FROM INSIGHTS
WHERE RESOLUTION_STATUS = 'Not Resolved'
AND CREATION_DATE >= :startDate
Chart widgets
Chart widgets (bar, pie, line) plot distributions or trends. The action query must return rows suitable for the chosen chart type, and xKey specifies which column to use as the category axis.
Observation data is stored in the Metrics/Assurance database. Two database types are supported:
| Database | Use case |
| SQLite | Development and local testing (Studio mode); zero configuration, file-based |
| PostgreSQL | QA and production environments; supports concurrent writes and large data volumes |
The database type is configured at the Fabric interface level. SQLite is used automatically when no PostgreSQL interface is configured. For production deployments, configure a PostgreSQL interface named METRICS_DB (or per your implementation's naming convention) in Fabric Studio.
Conversation tagging and signal extraction do not run automatically. Analysis must be triggered by running the RunAnalyze.flow or by the related Pipeline.
broadway aifusion.RunAnalyze 'day'='7'
The day parameter controls how far back to look. Sessions already analyzed (status CLOSED) are skipped.
Observation works out of the box once enabled, but several aspects can be configured to match your organization's monitoring needs: the application-level on/off switch, custom conversation tags, custom dashboard widgets, and the underlying database.
Observation is enabled or disabled in the web menu configuration file - apps.json
{ "displayName": "Observation", "pathName": "observation" }The auto-tagging system produces a standard set of tags for every conversation (Topic, Sentiment, Resolution Status, Risk Level, Follow-up Required). These are stored in the INSIGHTS table in the Observation database.
The signals extracted from each conversation are defined in the chat_signals.csv MTable. Each row defines one signal with its name, allowed values, and whether multiple values can be assigned (multi-select).
Default signals include: Topic, Sentiment, Resolution Status, Urgency Level, Follow-up, Complaint Severity, Upsell Opportunity, and others. Edit the MTable in Fabric Studio to add, remove, or modify signals for your domain.
Dashboard widgets are defined in the widgets MTable in Fabric Studio. Each row in this table defines one widget that appears in the Observation dashboard.
box (KPI card)
Displays a single aggregated value. The action SQL query must return a single scalar (e.g., a count or percentage).
Example - count of unresolved conversations:
SELECT COUNT(*) FROM INSIGHTS
WHERE RESOLUTION_STATUS = 'Not Resolved'
AND CREATION_DATE >= :startDate
Chart widgets
Chart widgets (bar, pie, line) plot distributions or trends. The action query must return rows suitable for the chosen chart type, and xKey specifies which column to use as the category axis.
Observation data is stored in the Metrics/Assurance database. Two database types are supported:
| Database | Use case |
| SQLite | Development and local testing (Studio mode); zero configuration, file-based |
| PostgreSQL | QA and production environments; supports concurrent writes and large data volumes |
The database type is configured at the Fabric interface level. SQLite is used automatically when no PostgreSQL interface is configured. For production deployments, configure a PostgreSQL interface named METRICS_DB (or per your implementation's naming convention) in Fabric Studio.
Conversation tagging and signal extraction do not run automatically. Analysis must be triggered by running the RunAnalyze.flow or by the related Pipeline.
broadway aifusion.RunAnalyze 'day'='7'
The day parameter controls how far back to look. Sessions already analyzed (status CLOSED) are skipped.