---
url: /v6.2/en-us/permission-faq.md
---
# 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:

* [Share Link](app-public-link.md)
* [Permission Settings](app-data-auth.md)

## 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:

1. **Build a Fusion dataset**: model the fact table and permission table together, then apply permission rules on the Fusion dataset
2. **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
3. **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:

* [Tenant Management](tenant.md)
* [Permission Management](permissions.md)