Article body
Full article
Using AI for enterprise analytics depends on preparing business semantics, available data, and access boundaries as conditions that can be maintained over time. Hengshi Data Agent supports conversational data analysis, metric creation, and dashboard authoring. Technical decision-makers and integration teams need to place these capabilities within existing data governance, authentication, and delivery processes. A business question can then develop from a single answer into an analytics asset that can be checked, refined, and reused.
1 From business questions to usable analysis: prepare semantics and data first
Data Agent can assist with on-demand business analysis, metric creation, and dashboard generation, but answer quality starts with whether data assets express the intended business meaning. Model-generated output assists analysis; data teams must continue to maintain business definitions explicitly. The Data Agent console supports prompts that supplement industry terminology, organizational rules, and analytical directions. Dataset knowledge management can describe purposes, implicit filters, synonyms, and the business meanings of fields and metrics. These configurations help connect questions to the right data objects instead of inventing critical rules within one conversation.
For example, departments may calculate “sales target attainment” using different target versions, time windows, or return policies. Teams should preserve the definition as a reusable metric, describing its reporting period, filters, and easily confused aliases, then place it in an appropriate dataset or business topic. Business users can ask questions based on an established definition, and analysts can return to that definition to verify results. The business topic and metric management manual describes where metrics, topics, and authorization are managed.
1.1 Data preparation is the first engineering task for answer quality
When publishing data packages and maintaining them, check dataset names, field types, field and atomic-metric descriptions, and hide fields that should not participate in question answering. Clear, concise context reduces ambiguity and irrelevant information. Complex calculations shared across teams should first become metrics. Individual conversations can explore, explain, and refine questions, but should not be the sole repository for critical business definitions.
Hengshi supports vectorization of text such as field names, atomic-metric names, descriptions, and field values, enabling semantic retrieval beyond keyword matching. Vectorization can retrieve synonyms, industry terms, and context, narrowing the candidates sent to the model. It does not replace data-quality checks, permission configuration, or validation of metric definitions. Official documentation also notes that identical inputs do not necessarily produce identical AI responses every time. Business and data owners should therefore confirm important conclusions together.
A practical preparation sequence is to confirm that datasets cover the required periods, grain, and data scope; complete names and descriptions for fields, atomic metrics, and business topics; record ambiguous terminology, default filters, and business rules in knowledge management or prompts; and run regression checks using real but desensitized questions. If a particular phrasing repeatedly selects the wrong object, first inspect synonyms, hidden fields, metric definitions, and data permissions rather than adjusting model parameters alone. Improvements then become part of the data assets available to subsequent users.
Data preparation also distinguishes exploration from publication. During exploration, business users can propose candidate questions in natural language, compare dimensions, and add context. Before publishing to operating dashboards, meeting materials, or downstream applications, confirm metric versions, periods, filters, data-refresh status, and owners. For conclusions intended for reuse, retain sample questions, corresponding metrics and data objects, and human-confirmed explanations. This small evidence chain helps new team members understand conclusions and identify what needs review after data or rules change.
1.2 Match the question scope to the role
ChatBI lets users choose datasets or business metric topics within their role permissions. In Agent mode, Data Agent can retrieve relevant content from the data marketplace, application marketplace, and application authoring within the user’s authorized data scope. On data-package, dataset, or dashboard pages, it can also use the current page and signed-in account as context. An explicit scope makes it easier to inspect which objects an answer references and which definitions apply.
2 Place capabilities within the right product boundaries
For business users, ChatBI starts with a clear question and returns data as charts; charts from the conversation can become a dashboard or be added to one. Data Agent spans a longer collaboration process: it can assist with conversational analytics, visualization and metric creation, HQL expressions, and changes to existing dashboards such as adding charts, filters, rich text, layouts, or colors. Its value is in extending an answer into an editable analytics asset, with modeling and review remaining part of the process.
Intelligent interpretation has another clear boundary. It can query, identify anomalies, decompose, and drill down according to a configured interpretation approach, then generate descriptive reports about existing and historical data. It does not forecast the future and does not support complex reports or complex tables. Causal attribution, prediction, and major business decisions require additional business hypotheses, external evidence, and human review.
2.1 Choose the execution mode before the integration method
Execution mode determines who continues the current question-answering process; integration method determines how the capability enters an existing system. Agent mode suits a continuous agent-driven interaction that can progressively produce status updates, tool calls, and chart results. Workflow mode advances execution through a backend workflow service, while the frontend primarily initiates requests, reads status, and displays results. When a backend needs to retain Agent mode, Hengshi provides a Node.js Agent service to host it.
| Combination | Primary responsibility | Suitable delivery goal |
|---|---|---|
| Agent + iframe | The embedded full page hosts continuous interaction and results | Reuse a complete ChatBI / Data Agent page quickly |
| Agent + JS SDK | The host retains its page shell and entry points while the embedded capability hosts frontend Agent execution | Preserve a continuous assistant experience in a business page |
| Workflow + JS SDK | A backend workflow advances execution while the SDK renders chat or results | Centralize execution and delivery timing in the backend |
| API | The integrator owns orchestration, presentation, and business integration | Integrate with an existing backend, AI gateway, multi-agent system, or workflow system |
An iframe reuses a complete page. The JS SDK preserves a custom page shell while embedding a full chat window or selected result cards. APIs provide backend capability integration. API is an integration method and is not equivalent to Workflow. Before choosing, establish who initiates requests, presents results, saves business assets, and handles failed delivery. The JS SDK data scope can use either data-package/dataset mode or business-topic-domain mode; a single configuration should not mix the two.
For frontend teams, an iframe offers a complete experience with fewer page changes. The JS SDK retains the host page’s entry points, layout, and interactions while reusing Hengshi chat, result cards, and chart presentation. Hosts that require their own presentation protocol and charting system must budget for frontend adaptation and testing; the SDK should not be treated as a chart-protocol converter. Backend API integration fits existing workflows, AI gateways, and multi-agent orchestration, but still needs explicit caller identity, data scope, error handling, and result-consumption destinations.
Confirm authentication and embedding early. Successful display of SDK questions and charts depends on a prepared login session. If SDK files load from a different static domain than Hengshi, the backend address must also be specified correctly. Before launch, integrate against the target deployment using real identities and minimum permissions, covering normal questions, unauthorized objects, expired sessions, and embedded-container dimensions. A loaded page alone does not establish that analytics can be delivered.
Continuous interactions should remain on the current page and session. Switching pages or historical sessions during Agent execution may interrupt the run, so retain the current page and session during demonstrations and troubleshooting. If work must resume across days or devices, the integrator needs to define backend tasks, state, and recovery ownership. A frontend question-answering process should not be treated as a promised durable recovery mechanism.
2.2 Configure models for observable delivery
Hengshi provides system-level settings for maximum model API output, timeout, call intervals, failed-call retries, random seed, and conversation history. Defaults listed in the public manual include a maximum output of 1,000 tokens, a 600-second timeout, one retry, and four conversation-history entries. Deployment teams should set them according to model-service capacity, network conditions, and business timing requirements, recording the deployed version and actual values. These settings control call behavior; they do not imply automatic routing by model capability or identical results across models.
Parameter governance should make failures predictable and manageable. Record how long to wait, how many retries to attempt, how much history to carry, and who may change configuration. Revalidate after model-provider, network-egress, or version changes. Interfaces should clearly indicate ongoing requests, timeouts, or the need to ask again. Operations records should correlate timestamps, versions, execution modes, and minimal reproduction questions. These records support integration and diagnosis; model-generated analytical text is not an audit conclusion that replaces business review.
3 Enforce permission boundaries on data objects
Authentication establishes who enters the system; permissions determine what they can do and see. For data connections, Hengshi supports permissions at connection, directory, and table levels to view names, view structures, access read-only, or access fully. Table-level read-only access can also have row and column permissions. For applications, the data-permission mode determines whether access uses the application author’s, dataset author’s, or viewer’s data. In application-author and dataset-author modes, application managers can further configure dataset row and column rules.
Treat rule combinations carefully. For the same user and dataset, row permissions and column permissions intersect; multiple rules of the same type are combined as a union. Row permissions on base datasets do not automatically propagate to newly joined downstream datasets, which need separate configuration. Business topics can authorize topic and metric use, but topic access must still be tested together with the underlying data package’s row permissions. Page filters, hidden controls, and embedded styling are not substitutes for data authorization.
3.1 Design a verifiable scope with least privilege
Work backward from actual usage. Determine which datasets or topics business users need, whether they need to inspect field structures, and whether they need to edit metrics or dashboards. Assign the minimum usable permissions on connections, directories, tables, applications, and topics. For table-level read-only access, row scope can use fixed values, user attributes, expressions, or SQL-expression filters, while column permissions hide fields that must not be exposed. Check every object in cross-table or downstream joined datasets rather than relying on automatic inheritance.
Do not validate with an administrator alone. Use at least an ordinary business account, an account at a permission boundary, and an account that should have no access to the scope. Test selectable datasets or topics, returned rows, sensitive-column visibility, and embedded results. If multiple rules match one user, check the final outcome against the product’s union and intersection rules. Recording account types, expected scope, actual results, and exception handling provides traceable acceptance evidence for permission changes, topic publication, and new datasets.
3.2 Close acceptance with a readable record
The checklist below combines data preparation, execution responsibilities, and permission verification. It is neither a Hengshi interface specification nor an internal product process; it helps integration teams retain inspectable evidence.
| Acceptance item | Facts to verify | Example evidence | Owner |
|---|---|---|---|
| Business semantics | Metric names, periods, filters, and synonyms are confirmed | Metric definitions and sample questions | Data owner |
| Question scope | Roles can select only authorized datasets or business topics | Scope screenshots or records from test accounts | Permission administrator |
| Execution and integration | Agent / Workflow responsibilities align with iframe, SDK, and API integration | Integration design and test results | Technical owner |
| Result review | Data, charts, and descriptive interpretations trace to data objects and definitions | Sample questions, filters, and human conclusions | Business owner |
| Failure handling | Timeouts, retries, page-switch interruptions, and user feedback are agreed | Configuration records and failure-drill conclusions | Operations and integration teams |
Example analytics acceptance record (an article example, not a Hengshi API request schema):
{
"analysis_topic": "Regional sales target attainment",
"scope": {
"mode": "business_topic",
"display_name": "Sales operations"
},
"verification": {
"metric_definition_checked": true,
"role_scope_checked": true,
"row_column_rules_checked": true,
"human_review": "Business owner confirmed the descriptive conclusions"
},
"delivery": {
"runtime_mode": "workflow",
"integration_surface": "js_sdk",
"test_result": "passed"
}
}4 Make AI analytics a reusable team capability
Hengshi Data Agent turns governed data, metrics, and application assets into a more natural analytics entry point, connecting conversational analytics, charts, dashboard editing, and descriptive interpretation. Reliable technical delivery requires four things: prepare semantics and data; choose execution and integration responsibilities; enforce permissions on connections, datasets, topics, and applications; and verify results through business review and integration records. AI becomes a trustworthy part of enterprise analytics when every answer can be traced to scope, definitions, and permissions.
This approach also supports continuous improvement. Frequent questions can inform metrics and knowledge management; recurring integration failures can become authentication, embedding, and execution-mode checks; and ambiguity found in business review can lead to clearer terms, rules, and descriptions. As data assets and delivery processes mature, teams gain an analytics collaboration process that business, data, and technical staff can maintain together, alongside faster individual answers.