Article body
Full article
Abstract: When business users spot late deliveries, falling sales, or inventory anomalies on a dashboard, their next step is often to continue breaking down and explaining the data and adjusting its presentation using the definitions already on screen, rather than restarting in an empty chat box. HENGSHI SENSE Data Agent can read signed-in account and current-page information, and assist with queries, visualizations, metric creation, and intelligent interpretation within data package, dataset, and dashboard pages. Reliable use starts with distinguishing what page context, conversation context, and saved assets each retain, then defining clear procedures for follow-up questions, failure recovery, and permission checks.
Start from the current page and identify context boundaries
The Data Agent sidebar addresses “How else can I analyze or create on the page I am viewing?” Public documentation explains that the Agent can read signed-in account information and use current-page information to handle queries on data package, dataset, and dashboard pages. It can also create a dashboard from scratch on the dashboard list page, or edit existing dashboards, including charts, filters, rich-text reports, layouts, colors, and controls. Dashboard pages can configure intelligent interpretation, using preset reasoning directions to drive queries, anomaly detection, decomposition, and drill-down, producing descriptive reports based on existing and historical data.
“Reading the current page” does not mean that all information on it automatically becomes a correct answer. Implementation teams should break context into inspectable fields: the signed-in user and data permissions; current resource type and identifier; selected data package, dataset, or dashboard; the current chart’s measures, dimensions, time granularity, filters, and parameters; the control or chart being edited; unsaved draft state; and questions and preferences introduced in the current conversation. Identity and resource scope determine allowed access. Chart bindings and filters determine query definitions. Editing and draft states determine whether subsequent actions may change page assets. Teams should verify the actual availability of these fields in their own pages, versions, and permission models, rather than treating “page context” as unbounded memory.
ChatBI has a different starting point. It suits a standalone intelligent data-questioning entry point and can generate charts and dashboards around a conversation. The public FAQ lists “generate a dashboard from conversation charts in one click” as a ChatBI capability. The Data Agent sidebar assists with visualization, metric creation, and intelligent interpretation, but does not provide that same one-click path. Both entry points can serve the same authorized data, but their conversation state, page state, and write paths must not be assumed to interoperate automatically.
Illustrative implementation: continuing analysis on a late-delivery procurement dashboard
This is an illustrative implementation scenario, not a customer case or an actual outcome. A procurement lead opens a “This month’s delivery fulfillment” dashboard. It already has a current-month range, procurement-organization filters, and defined metrics such as “late delivery order count,” “days late,” and “on-time arrival rate.” Detail rows include supplier, promised arrival date, actual arrival date, order status, and category. The lead enters: “Explain this month’s late deliveries, then break them down by supplier. Change only the chart styling and keep the metric definitions.” This combines query, follow-up, and editing intent.
First, confirm whether “this month” inherits the dashboard’s time filter or specifies a new calendar month at question time; and whether “late delivery” inherits an existing metric or needs a temporary calculation from promised and actual arrival dates. Prefer existing governed metrics where available, and check the source, procurement organization, time window, and excluded statuses. Data Agent can retrieve and query within permission scope and split a complex question into one or more queries. Business users still need to check returned time ranges, filters, measure names, and grouping dimensions against the dashboard before explaining causes.
Second, “break down by supplier” should inherit the confirmed month, procurement organization, and late-delivery definition, replacing the previous analytical dimension, such as trend or category, with supplier. “Only show the East China warehouse” needs an added or replacement warehouse filter. “Change to last quarter” replaces the time filter; the current-month context must no longer apply. Checking what each follow-up inherits, replaces, and adds makes changes in business definitions visible.
Third, “change only chart styling and keep the metric definitions” is page authoring. Keep measures, dimensions, filters, and data bindings unchanged, and adjust only colors, labels, layouts, or control styles within what the chart type permits. “Change overdue rate into a supplier risk score” introduces a new metric or calculation definition. It requires renewed agreement on formula, aggregation grain, sources, naming, review responsibility, and save location. Combining these request types makes it easy for metric definitions to drift unnoticed while the dashboard’s appearance changes.
Queries, edits, and metric creation cross different state boundaries
| User intent | Page state that can be inherited | Boundary requiring explicit confirmation |
|---|---|---|
| Explain this month’s late deliveries | Current source, time range, organization filters, defined metrics | Late-delivery definition, excluded statuses, whether explanation uses only returned data |
| Break down by supplier | Confirmed measures, time range, and filters | Which dimension supplier replaces; whether category and warehouse filters remain |
| Change only chart styling | Data bindings, chart data, definitions, and page position | Permitted style changes, whether they write to the dashboard, save permissions |
| Create an HQL expression or metric | Relevant dataset and business terminology | Formula, aggregation level, metric name, reviewer, and asset ownership |
| Call a backend or external workflow | Request parameters explicitly supplied by the integrator | API support, calling identity, data scope, and write actions |
Data Agent can assist with complex expressions and metric creation using its understanding of HQL. This helps turn explicit business rules into reviewable candidate expressions. It does not replace metric governance: the same “late-delivery rate” differs when calculated by order count, order value, or line items. Whether the denominator excludes canceled orders and whether the date is promised or actual arrival must also follow business rules. Important definitions should become data-side metrics with documented numerators, denominators, time windows, and synonyms. A temporary conversational calculation must not silently become a lasting standard.
APIs also do not expose every in-browser authoring capability unchanged to external systems. The public FAQ lists visualization assistance, metric creation assistance, and intelligent interpretation as Agent-mode capabilities, without listing equivalent capabilities for Agent API or Workflow API. Public integration guidance likewise positions APIs as backend orchestration entry points. Projects calling from their own systems should check each query, rendering, and asset-writing capability against interface documentation, and redesign calling identity, supplied context, and permission validation accordingly.
Make follow-up analysis reviewable
Conversation continuity can improve interaction efficiency but cannot replace validation. Data preparation should precede prompt tuning: clear dataset, field, and metric names; complete descriptions; hidden irrelevant fields; and dataset knowledge containing terminology, synonyms, and implicit rules all affect retrieval and understanding. Official documentation also warns that AI behavior is uncertain and identical inputs do not guarantee identical responses. Explicit questions can reduce ambiguity, but prompts cannot substitute for data governance.
After each important follow-up, operators should check the execution log’s actual data sources, metrics, filters, and errors. If a query returns data but chart editing fails, record “analysis result obtained” separately from “page asset not written.” If saving fails, retain the original dashboard and candidate changes, investigate permissions, resource locking, or configuration conflicts, and then retry. After a successful save, reload the dashboard as the same user and confirm that chart, filter, and metric bindings remain. Then verify read/write boundaries using an account with lower editing permissions or the project’s review process. This keeps temporary conversation results, unsaved drafts, and published dashboards distinct.
Use later-version information to design upgrade checks
The 6.2.5 changelog mentions fixes involving second-round ChatBI data-source inheritance, conversation scope, and preferences saved but not applied. These can become post-upgrade regression scenarios: after the first procurement-dashboard query, ask for a supplier breakdown in the second round and check source continuity; switch or return to a conversation and verify request scope; save display preferences, re-enter the page, and check that they actually apply. Release records show that these issues entered the fix scope. They do not prove that every live environment has the same problems.
HENGSHI’s view: Page context lets business users continue questioning an existing dashboard. Governed metrics keep breakdowns on consistent definitions. Clear save and permission boundaries make authoring results reviewable. Connecting these three lets Data Agent support maintainable analytical work beyond a convenient one-off answer.