Use Cases
Use cases for signed embed
Case: Utilizing Embedded Dashboards in Retail Support SaaS
Scenario
In a SaaS platform that supports retail store operations, we assume a need to embed dashboards within the SaaS to understand sales performance and KPIs for each store. This functionality allows store managers and area managers to view only information related to their stores when they log in.
Notebook Parameters
The notebook that serves as the source for signed embed is assumed to have the following parameters configured:
tenant_id
:Tenant ID to which the logged-in user belongs
"Text input" type parameter
store_id
:Store ID for which data is to be displayed
"Text select" type parameter, where options allow selection of store IDs within the tenant specified by
tenant_id
date_range
:Data aggregation period
"Date range" type parameter with a default value of relative dates spanning 7 days from the previous day
product_category
:Product category for narrowing down data aggregation targets
"Text multi select" type parameter, with SQL conditions specified to display all product categories when none are selected
Configuration Example A: Using Signed Embed Forms
Prerequisite Notebook Design
Security of data accessible to users is ensured by fixing
tenant_id
SQL for data extraction always specifies
tenant_id
as a filter conditionFor example, when extracting store data, both
store_id
andtenant_id
are specified as filter conditions, preventing extraction of data from stores belonging to different tenants
date_range
andproduct_category
are designed to allow arbitrary values
Parameter Configuration
tenant_id
: Server-side fixed valuestore_id
: Server-side initial valuedate_range
: Client-side parameterproduct_category
: Client-side parameter
Flow to Display
Token issuance on server-side
Specify the user's
tenant_id
as a server-side fixed valueSpecify the
store_id
to display in the initial state as a server-side initial value from among thestore_id
values associated withtenant_id
Initial rendering process on front-end
When sending the
SET_TOKEN
message, send the following client-side parameters together:date_range
is specified to reset to default value for relative date recalculationproduct_category
is specified with an empty array as the initial value
User dashboard operations
Users can change
store_id
,date_range
, andproduct_category
from the dashboard form
Configuration Example B: Managing Parameters on SaaS Front-end
Prerequisite Notebook Design
The same design as "Configuration Example A"
Parameter Configuration
tenant_id
: Server-side fixed valuestore_id
: Client-side parameterdate_range
: Client-side parameterproduct_category
: Client-side parameter
Flow to Display
Token issuance on server-side
Specify the user's
tenant_id
as a server-side fixed value
Initial rendering process on front-end
When sending the
SET_TOKEN
message, send the following client-side options together:Since parameters are managed on the SaaS side, specify the option to hide the parameter form (
displayOptions.hideParamsForm = true
)Specify values managed on the SaaS side for
store_id
,date_range
, andproduct_category
User dashboard operations
When changing dashboard display conditions due to changes in conditions managed on the SaaS side, follow these steps:
Reuse the token used in the initial rendering process and resend the
SET_TOKEN
message with updated client-side optionsBy resending the
SET_TOKEN
message, the dashboard is redrawn based on the newly sent client-side optionsThe client-side parameters sent at this time must include all items (
store_id
,date_range
,product_category
), not just the differencesWhen the same user uses the same server-side fixed value, token reuse is possible (note the expiration time)
Configuration Example C: Updating Server-side Fixed Values
Prerequisite Notebook Design
Security of data accessible to users is ensured by fixing both
tenant_id
andstore_id
Unlike "Configuration Example A", this assumes a case where
store_id
needs to be fixed on the server-side
date_range
andproduct_category
are designed to allow arbitrary values, same as "Configuration Example A"
Parameter Configuration
tenant_id
: Server-side fixed valuestore_id
: Server-side fixed valuedate_range
: Client-side parameterproduct_category
: Client-side parameter
Flow to Display
Token issuance on server-side
Specify the user's
tenant_id
and thestore_id
to display in the initial state as server-side fixed values
Initial rendering process on front-end
When sending the
SET_TOKEN
message, send the following client-side parameters together:date_range
is specified to reset to default value for relative date recalculationproduct_category
is specified with an empty array as the initial value
User dashboard operations
Since
store_id
is a server-side fixed value, it cannot be changed from the dashboard form, and the SaaS side needs to managestore_id
and provide a form for changing the target storeWhen redrawing the dashboard by changing
store_id
based on user operations, follow these steps:Issue a new token to the server-side specifying the new
store_id
, and send theSET_TOKEN
message with the new token and client-side parametersTo change server-side fixed values, token reissuance is required
Client-side parameters must include all items (
date_range
,product_category
), not just the differencesTo preserve
date_range
orproduct_category
changed by user operations, record thePARAM_CHANGED
messages sent from the iframe and send them during redrawing
For
date_range
andproduct_category
, users can change the display content from the dashboard form
Last updated
Was this helpful?