Multi-tenant

In a signed embed, using fixed values for server-side parameters lets you isolate the data each tenant in the embedding destination can view. You can reuse a single notebook for multiple tenants while ensuring each tenant can only view their own data.

See Signed embed for the parameter types, Integration steps for the integration steps, and Use cases for concrete design examples.

Roles of each parameter

Type	Purpose
Server-side parameter fixed value	A condition, such as a tenant ID, that viewers must not be able to change. It's not shown in the input form.
Server-side parameter initial value	A value such as the store ID shown initially. The initial value is specified server-side, and can be changed from the input form afterward.
Client-side parameter	A condition, such as a date range or category, specified dynamically from the input form or the embedding app.

WARNING

On the SQL side, always include the fixed-value parameter in your filter conditions. If you only filter on a lower-level identifier, such as a store, you might unintentionally allow access to another tenant's data.

Configuration examples

Using the input form on the signed embed side

1. Make the tenant ID a fixed value, the initially displayed store ID an initial value, and things like the date range client-side parameters.
2. Issue a token server-side, including the fixed value and initial value in params.
3. Pass the client-side parameters when initializing the embed.
4. Viewers can change the initial value and the client-side parameters from the input form.

For details, see Use cases: Configuration example A.

Managing parameters on the embedding app side

1. Make the tenant ID a fixed value, and everything else client-side parameters.
2. Issue a token server-side, including the fixed value in params.
3. Enable hideParamsForm when initializing the embed, and pass the values managed by the embedding app as client-side parameters.
4. To update the conditions, reuse the same token and resend the full set of client-side parameters. You can't send only the diff.
5. If the same viewer uses the same fixed value, the token can be reused within its expiration period.

For details, see Use cases: Configuration example B.

Updating a fixed value

If you also make something like the store ID a fixed value, changing the target store requires reissuing the token.

1. Reissue the token server-side, specifying the new fixed value.
2. Send the new token and the full set of client-side parameters to the embed.
3. If you want to preserve client-side parameters the viewer changed before the redraw, record the change notifications sent from the embed and include them when resending.

For details, see Use cases: Configuration example C.