> ## Documentation Index
> Fetch the complete documentation index at: https://docs.omni.co/llms.txt
> Use this file to discover all available pages before exploring further.

<AgentInstructions>

## Submitting Feedback

If you encounter incorrect, outdated, or confusing documentation on this page, submit feedback:

POST https://docs.omni.co/feedback

```json
{
  "path": "/embed/best-practices",
  "feedback": "Description of the issue"
}
```

Only submit feedback when you have something specific and actionable to report.

</AgentInstructions>

# Embedding Omni best practices

> Learn how to develop a secure, enjoyable embedded Omni experience for your users.

## Define base connection roles

When generating embed requests, set the [`connectionRoles`](/embed/setup/url-parameters/connectionRoles) parameter to either **No Access** or **Viewer**. This sets the default level of access for the connection and ensures that access to data must be granted on an individual user basis.

## Leverage user attributes to control data access

To ensure appropriate data access for users, best practice is to leverage [user attributes](/administration/users/attributes) to systematically filter data.

* **Access filters**, or row-level security, allow you to restrict the rows of data a user can access within a topic. Access filters apply the values assigned on a user attribute to the `WHERE` clause of every SQL query a user runs, filtering out to only the data designated to that user.
* **Access grants** define topic- and field-level permissions for users

## Implement security for multi-tenant instances

<Warning>
  Segmenting data using hidden dashboard filters is not a secure practice.
</Warning>

Typically, companies choose one of the following strategies to set up multi-tenant customer data:

* **Row-level security** - If all of the data is inside one table, you can assign a user attribute per user and client and use it as an [access filter](/modeling/develop/data-access-control). Specifically make sure to set up a default access filter to control in Omni with [`default_topic_access_filters`](/modeling/models/default-topic-access-filters).
* **Schema level security** - If each client is in a separate, identical schemas then you can leverage [dynamic schemas](/modeling/models/dynamic-schemas).
* **Database level security** - If each client is in a separate database and the schemas are identical across databases, you can leverage [dynamic database environments](/connect-data/dynamic-environments).
* **Model-level isolation** - If each client needs a tailored view of the same base model, you can use [shared extension models](/modeling/develop/shared-extensions) to create tenant-specific extensions that inherit core logic while allowing per-client customizations.

## Build content on shared topics

Embedded dashboards won't render correctly if the content you want to embed meets **any** of the following criteria:

* Content contains fields not included in a topic in the shared model
* Content built on SQL
* Content that contains unpromoted changes to joins in the workbook's model

<Warning>
  To expose non-topic bound or SQL-based content, enable [**AccessBoost**](/share#boosting-permissions-with-accessboost) in the content's **Share** settings. **This has security implications**, as you may expose data that you don't want your embed users to access.
</Warning>

## Save content to the Shared hub

Along with the above criteria for building content on topics, embedded dashboards must be saved in your instance's **Shared** hub. Dashboards will not render correctly if they are saved in personal folders.