App Delivery and Template
Many "why is this different after import?", "why can't the other person continue editing?", or "why is the published app different from the authoring area?" questions are really about delivery boundaries that were never made explicit. This page turns those repeated questions into a practical FAQ.
Why is the published app not kept in realtime sync with the authoring area?
Because a published app is a snapshot taken at publish time.
That means:
- changes made later in the authoring area do not flow automatically to the published app
- the published version stays unchanged until you republish
So if the authoring area already looks correct but viewers still see the old version, do not start with cache suspicion. First check whether the app was ever republished.
Why does an app template exported from environment A show "dataset package does not exist" after importing into environment B?
A very common reason is that dataset package IDs do not match across environments.
IDs are usually auto-incremented per environment. Even if you imported the template and replaced the connection in environment B, charts may still reference the original environment's dataset package IDs.
The fix is usually not rebuilding the template. It is:
- manually replace the dataset package in environment B
- confirm that template dependencies now point to dataset packages that really exist in the target environment
What are templates good for, and what are they not good for?
Templates are good for:
- platform-to-tenant or enterprise-wide delivery of standard analysis skeletons
- reusing app structure across repeated business scenarios
- report apps that need unified layout and complex report templates
Templates are not good for:
- target environments with very different structure
- expecting a truly zero-configuration import
- automatically resolving all cross-environment IDs, permissions, and connections
If target data structures differ, templates help reuse the shell, not erase every migration difference.
Do template-market templates carry the original live data out with them?
Not in the sense of directly carrying live production data.
When an app is put on the template market, its datasets are converted into Excel file datasets as sample data for template display. So before turning an app into a template, confirm that the sample data is acceptable for template consumers to see.
Should I use collaboration, create a copy, or export a template?
Choose by goal:
| Goal | Better fit |
|---|---|
| Multiple people continue editing the same app together | Collaboration |
| Someone should fork the current app and evolve it independently | Create a copy |
| Reuse an app skeleton across environments or teams | Export a template / create from template |
If what you really want is "give someone an independently evolving version," do not only collaborate the original app to them.
Why can collaborators edit app content but not publish it or collaborate it onward?
That is the default boundary of app collaboration:
- collaborators can edit the inside of the app almost like the owner
- but they cannot publish, delete, or re-collaborate the app outward
This keeps internal co-editing separate from formal outward delivery.
When should I prefer app hash over app id?
Prefer app hash when the published app is also used in:
- embedded analytics
- page navigation
- custom JS
- external systems that store app links
Because after republishing, app id changes while app hash stays stable. External integrations tied directly to app id are much easier to break.
What is most often missed in cross-app chart copy?
The most common miss is that the target dashboard layout has to be prepared explicitly.
Cross-app chart copy needs more than the source chart id and sourceAppId. The caller also has to organize the target dashboard layouts and include the layout structure expected by the import API.
So this is usually not "the API cannot do it." It is "the caller did not prepare the target dashboard layout state completely."
Why do report apps still need field dragging and filter setup after importing a template?
Because templates reuse layout and structure, not complete business-data mapping.
For complex reports, importing a template usually still requires:
- dragging business fields into the designated cells
- rebuilding filter areas
- previewing and publishing again
If "import template" is understood as "one-click finished report generation," the real boundary will be misunderstood.
Further reading: