Permission Model
Permission questions usually come from the gap between "what I expected" and "how the system actually defines access rules." This page focuses on the high-frequency topics: public links, data permission modes, row-level permission modeling, and platform/tenant authorization boundaries.
Why does User mode not support public links?
Because a public link means "anyone with the link can open it directly," while User mode means "data visibility depends on the current logged-in user."
If the visitor does not log in, the system does not know who the current user is, so it cannot evaluate data by user identity. As a result:
- App Author / Dataset Author modes can support public links because the result is fixed
- User mode cannot support public links because it depends on login identity
Related docs:
How should I choose between App Author, Dataset Author, and User modes?
A simple rule of thumb:
| Mode | Good fit | Bad fit |
|---|---|---|
| App Author | Everyone should see the same result | Results must change by logged-in user |
| Dataset Author | The most common and safest default for shared analysis | Strict user-by-user data slicing |
| User | Data must follow the current logged-in user's permissions | Public links or acceleration-engine scenarios |
For collaborative analytics, Dataset Author is usually the safest choice because results stay stable and easier to explain.
Why can User mode not use the acceleration engine?
Because the acceleration engine works by solidifying results for reuse, while User mode requires results to change by current login identity.
Those goals conflict. If your business logic must slice data dynamically by user identity, the design usually belongs in direct queries, connection permissions, or row-level permission modeling instead of expecting the acceleration engine to preserve user-specific behavior.
How should row-level permission be modeled when there is an independent permission table?
This is a very common support scenario. Three common approaches are:
- Build a Fusion dataset: model the fact table and permission table together, then apply permission rules on the Fusion dataset
- Use the permission table as a model-side table: when joining the fact table and permission table, pay attention to join direction and always-on effect rules
- Introduce the permission table through dataset filtering: useful when direct modeling is undesirable or many-to-many relationships would create data expansion
If the permission relationship itself is complex, start by classifying whether the relationship is one-to-one, one-to-many, or many-to-many before choosing the implementation pattern.
Why can a tenant see a platform-shared data package, but regular tenant users still cannot?
The default model is strict authorization:
- The platform grants the resource to the tenant
- The tenant admin decides whether to grant it further to regular users inside that tenant
So "the tenant can access it" and "every regular tenant user can access it" are not the same thing.
If you need a looser default behavior, evaluate whether PLATFORM_FOLDER_AUTH=read matches your governance policy. That kind of configuration changes the default visibility boundary between platform and tenant, so it should be a deliberate decision followed by a restart.
Further reading: