← Back to Technical blog

Technical article

Keep Analytics Inside the Business System: Delivery Priorities for HENGSHI Embedded Analytics

Delivery priorities for HENGSHI embedded analytics: business page context, metric definitions, identity mapping, permissions, and acceptance in the host product.

Nov 3, 2026Technical blogHENGSHI11 min read
Embedded AnalyticsSaaSHENGSHI SENSE

Article body

Full article

When project managers check task progress in a business system, they often also want to know which teams account for delays and which projects drive cost variances. If analytics lives in another system, users must find the project again, set filters, and carry conclusions back to their original work page. SaaS vendors need to deliver a product experience that supports these business questions.

Choose the business page before choosing what to embed

In a project management application, a project home page can show delivery progress and a budget overview. Within an individual project, users need to examine variances by phase, team, and time. Partners can prepare datasets and analysis assets in HENGSHI SENSE, then embed dashboards or analytics entry points in the relevant pages. Users can inspect related data while working on a project, instead of locating the business object again in a generic report.

Before embedding, decide which context the host page passes, such as the current project, organization, and time range, and how those parameters map on the analytics side. Displaying charts is only the first step. Analytics becomes part of the workflow when its filters match the business page.

Give every entry point a page contract

Product and implementation teams should map each host page to its analytical content before embedding. The project home page may address a portfolio, the detail page an individual project’s cost and progress, and the approval page only the risk signals for the current item. Identify the decision users need to make on each page, then choose charts and interaction depth. Putting the same large dashboard on every page still leaves users searching for answers.

Business entry pointContext passed inExpected analytical contentAcceptance action
Project listOrganization and time rangePortfolio progress and variancesChange organization and reconcile totals
Project detailsCurrent project and time rangeThat project’s phases and cost detailsChange project and check titles and data
Approval pageCurrent project or itemA small set of approval-related metricsInspect an exception, then return to approval

This table starts a delivery discussion; it is not a fixed product template. Teams must also specify where parameters originate, what appears when they are missing, whether users can filter further inside analytics, and how filter state behaves after returning to the business page. If a user selects “last three months” in project details and then opens another project, should the time range persist or reset? Frontend, backend, and analytics implementation teams need to test against the same agreement.

Accept mobile and narrow layouts separately. A dashboard readable on desktop may become unusable inside a smaller business page. Designers can retain one key conclusion and the necessary filters, moving complex details to a more suitable page. After opening an exception project, users should know how to return to the original task.

Connect metric definitions and user identities together

HENGSHI provides data connectivity, modeling, metric management, visualization, and embedded integration. Partners can define calculations, qualifying conditions, and analysis dimensions in metric management, then reuse accepted metrics across pages. Order value, collected payments, and budget utilization each have their own definitions. Sharing a dashboard does not make their calculation bases interchangeable.

Authentication and permissions need to be designed with the host product. HENGSHI SENSE offers integration paths including single sign-on and JWT, as well as permissions for applications and data resources. Multi-tenant deployments also require checks of tenant spaces, user mapping, and row-level data scope; the relevant capabilities must be confirmed against licensing and deployment plans. During acceptance, implementation teams should enter the host pages separately as platform administrators, tenant administrators, and ordinary users, checking what pages and data each role sees.

Accept delivery inside the original product

Before launch, walk through a real task: enter analytics from a project page, change the time range, inspect an exception project, and return to a task or approval workflow. Check loading, linked filters, permission messages, and mobile layout. Also confirm that, after data refreshes, the dashboard and business system still refer to the same project. Data differences should be traceable to metric definitions, datasets, and permission settings.

Acceptance samples should cover the page paths people actually use. Start with one project containing data and another containing none. Enter their detail pages from the list and reconcile the selected project, chart titles, filters, and totals. Analytics must change when users select another project. Return to the list and reopen the first project to check for an incorrectly retained filter state.

Separate different meanings of “cannot see it” during permission checks. Being logged out, having an expired session, lacking access to the analytics entry point, and seeing summaries without access to details are four distinct scenarios. The host product should provide understandable messages, while the implementation team checks identity mapping and data authorization on the analytics side. In multi-tenant deployments, test isolation with identically named projects in two tenants rather than accepting delivery with an administrator account alone.

Delivery records can retain the entry page, business object passed in, test identity, expected result, and actual screenshots. After a product redesign or an analytics asset change, partners can use these records to retest key paths, then ask the customer’s business owner to check figures and terminology. Both the page experience and metric results then have identifiable owners.

Keep observing actual use after launch

Acceptance can be organized around three points: confirm metrics and identity mapping before a pilot, record users’ paths from entry to action during the pilot, and retest tenants and roles before wider rollout. A pilot should ask more than whether charts load. Can a project manager move from an exception figure into the project handling process? Must users copy data elsewhere to discuss it? If they repeatedly bypass embedded entry points for standalone reports, revisit placement, chart content, and filters.

Product redesigns alter page paths and parameters; organizational changes alter data visibility; upgrades to analytics assets may change chart names. Partners can retain a regression sample set for key entry points: a project with data, one without data, a restricted account, and a cross-tenant isolation scenario. Run these samples after every change, then have the customer owner check business meaning. “It worked last time” can then be tied to a specific entry point, identity, and version, rather than becoming guesswork across systems.

Long-term use also needs clear responsibilities. The host product team owns entry points, navigation, and user messages; the data team owns datasets, metrics, and refreshes; the customer’s business owner confirms which figures support daily decisions. On finding inconsistent data, first retain the business object, filters, access identity, and viewing time, then investigate by responsibility. A small, clear delivery record helps continuous improvement more than additional charts.

A practical sequence for a customer walkthrough

Consider a project manager checking delay risk: they identify a lagging project in the list, enter details to examine phase-level progress and cost, and return to the task list to find its owner. The implementation team can check every screen: does the project ID in the list match the analytics area, does the detail page’s time range follow the page selection, and can a user return to the original task after selecting an exception? If users must copy the project ID and search for it on a separate analytics page, entry point placement or context passing still needs improvement.

Walk the same path with a restricted account. If it has access only to project summaries, avoid presenting clickable detail entry points it cannot open. If the entire project is unavailable, the host page and analytics area should give consistent permission outcomes. Also test everyday actions such as signing out and back in, refreshing after session expiry, and using the browser’s Back button. Breaks in the experience often occur during these transitions rather than on the first dashboard load.

Finally, ask the customer’s business owner to explain the chart’s conclusion in real business terms. If “budget variance” includes unapproved expenses in the system but the customer understands it as incurred expenses, even fast loading and correct arithmetic do not justify delivery under that name. Return to the metric definition, agree on the name, explanation, and page hints, then complete acceptance. Embedded analytics is delivered when users can make judgments on their original work pages; technical connectivity is one part of that result.

HENGSHI’s value is in organizing data preparation, metrics, and visualization into an analytical foundation that partners can integrate into their own products. Partners remain responsible for choosing business entry points, defining customer-ready metrics, completing authentication mapping, and accepting the final experience. Analytics delivered this way can be used and improved through customers’ everyday work.

HENGSHI SENSE

Resources, ecosystem, and implementation stories

Explore how teams design and ship analytics with HENGSHI.

Request a trial

Enterprise deployment, embedded delivery, and trial requests can all be handled quickly.