This QuickStart introduces you to Sigma Application Embedding and demonstrates how to embed Sigma content in a public website. This QuickStart assumes you have already taken the QuickStart Embedding 1: Prerequisites so that you have a sample environment to complete the tasks in this QuickStart.
There are three "modes" that Application embedding can be operated in; View, Explore and User-backed.
User-backed is by far the most popular mode as that works the the Parent application's authentication to pass user-level permissions. WIth this method each user is treated as an individual, with an account type and team permissions. We will refer to these individuals as embed users.
User-backed is used to implement row-level security (RLS) at the team and user level and also allow embed users to save and edit their own versions of embedded workbook
View and Explore modes are used then the user is not known by the Parent application but the embed still requires security.
The most common User-backed use-case (or experience) that our customers use are shown below.
Sigma also allows you to extend or create custom experiences as well. We will demonstrate each of these three later in the QuickStart.
Semi-technical users who will be aiding in the planning or implementation of Sigma, embedded into a secure website. No SQL or technical data skills are needed to do this QuickStart. It does assume some common computer skills like installing software, using Terminal, navigating folders and edit/copy/paste operations.
The exercises in this QuickStart will discuss and walk you through the steps to:
We will embed Sigma content inside a Node.js web application, passing runtime parameters to configure the embed and demonstrate Account Type use-cases.
Embedding is a way to securely embed your data without your users needing to authenticate through Sigma. This "authentication pass-through" is a key feature of Sigma's embedding model and makes it fast to implement as well.
Application embedding is the most popular method for including Sigma content because it fully supports high security and the ability to pass parameters and more. Passing parameters creates a personalized user experience in addition to other Sigma functionality we will explore later.
Application embedding is made possible by the creation of a unique and encrypted embed URL pointing to the workbook, workbook page, or element you wish to display. This URL is generated on the server side of your Parent application, accessed through an API you set up (we will show you an example in this QuickStart), and rendered client side in an html iFrame element.
When you create the API to generate your embed URL you can specify parameters that define who the user is, what role they have (Account Type / Team membership), what they will see and how they can interact with your embedded content.
With that in mind, User-backed users are assumed not to exist in Sigma's Users list; the user information will be passed at run-time to Sigma by the Parent application. Of course, you can still have manually created Sigma users for administration purposes. This saves you time and management overhead. This does not matter to the anonymous user modes (View and Explore).
Also very important to know that each API generated URL can only be used once and if modified externally and resent, will generate an error message in the browser.
The flowchart below provides a high-level overview of how User-backed Application embedding works for Sigma, step-by-step. The steps for anonymous users are similar but there is no user authentication passed from the Parent application.
To embed, you will need to complete a few steps in Sigma and your Parent application. This requires implementation of client and server-side code. The workflow below demonstrates the minimum steps involved so that you may see the process all at once before we do each step.
Before we can work on the content we need to provision Account Types
, Teams
and Workspaces
in Sigma for our QuickStart. This will allow us to group users and set various permissions.
Log into Sigma (as an Administrative user).
Sigma is very flexible, at a high level the following describes the permission hierarchy:
User Account Types: A user's account type determines their highest level of interaction with data and content in Sigma. Each user is assigned a single account type; they can only be assigned one account type at a time. More information can be found here: User Account Types
Teams: allows for organized management of user groups. To view and interact with User-backed embedded workbooks, a user must be assigned to at least one team in your organization. Users can be members of more than one Team. Data source permissions can be granted to entire teams. This option is also available for folders and documents. For team members or individual users to save and edit versions of embedded workbooks, they must have Contribute access to a workspace. More information can be found here: Teams
Workspaces: allows folders and documents to be compartmentalized, categorized, and easily shared with the correct people. They can be shared amongst users and teams via permission grants. Workspaces are managed by organization admins. Admins also have access to an additional ALL WORKSPACES
tab. More information about can be found here: Workspaces
We will use Account Types to allow different users different rights as we go through the use-cases. Sigma provides a few default types and we create two additional. Navigate to Administration / Account Types.
The Viewer Account Type already exists so we will just use that as is. Here are the settings:
Create a new Account Type called Viewer+
and set it as follows:
Create another new Account Type called "Explorer" and set it as follows:
When done your Account Types should look like:
Navigate to the Administration
Teams
page and use the Create Team
button to add two new Teams. Tick the checkbox to also create a Workspace. We will use this later to share user created content directly from the Embed.
We will call our teams FinanceViewers
and FinanceCreators
.
Exiting Administration (upper left corner Sigma Back Button or click the papercrane icon) you can click on the Workspaces
menu item and see that this also created a Workspace for each Team. This is useful when we later want to save the default Workbook as a copy, make changes and share with the rest of the Team. This functionality provides a lot of flexibility in how your users access shared work.
From the Workspaces menu
, share
the FinanceViewer Team to add FinanceCreator
s setting Access Type to Can Contribute
. This will allow members of the FinanceCreators Team to share data to this Workspace.
In this step we are logged into Sigma as Administrator and will create a curated set of data that we will expose to others via their Account Team later.
To leverage the features in User-backed embedding you must grant permissions to your data. Creating a Dataset and setting permissions on it is considered best practice.
From Sigma / Home
click the +
Create New button and click Dataset
:
We will use Table from the options; click Select under Table:
We will use sample data as in other QuickStarts as below. You must first select a Connection
. Use the Sigma Sample Database provided and then use the PLUGS_ELECTRONICS_HANDS_ON_LAB
table as shown:
Once you have selected the table it will show it and then you can click the Get Started
button:
Change the name of the new Dataset to Application Embedding
by just double-clicking over the existing name. Then click Publish
.
Click the caret (▼) to the right of the Dataset name. We will want to save this Dataset in a place we can easily find it later. Create a Workspace
folder called Datasets
to save this one in. Click Move after you have navigated to where you want to save the Dataset.
We now have a Dataset but users have no ability to view them yet. We can consider this our data library and we can decide who else can work with each Dataset. We will share the "Application Embedding" Dataset.
Click Permissions
and the Add Permission
button. Add permission for the Finance Teams as below. Since users will be coming in with different Account Types, adjusted at runtime, we will use View rights
for now.
Uncheck the send email checkbox. Click Save
. Click Publish
(if it was not already Published).
You now have a Dataset that is available to users in our Application embeds, on the Finance Team.
From Sigma / Home click the + Create New button and click Workbook
and add a Table to it. We called ours Application Embedding
.
Select Tables and Datasets
. You will have to use the navigation in the modal, click back and find the location where you saved the Dataset. Choose your Dataset and click the Select button:
Click Publish
. A Workbook must be published to create or manage embeds.
The Workbook is now ready for Application embedding. The Workbook looks like this:
Share the workbook with the Finance Teams. Click the caret (▼) icon button to the right of the workbook title in the header and click Share. Untick the send email checkbox and click Save.
We are now ready to work on the first Application embedding use case.
We will create the Embedding information that we will pass to the developer of the Parent application (in this case the developer is us but not always).
Click the caret (▼) icon button to the right of the workbook title in the header.
Click Embedding
to open the Application tab.
Under Generate Application Embed Path
for, select your embed target. We selected the Entire Workbook.
The embed path will automatically be generated. Click Copy
to copy this path. Save this off to a text file for later use. Close the modal.
To create an Application embed, you will need an embed secret. This secret will be used server-side and encrypted in your embed URLs to ensure your application embed URLs are valid at run-time.
You cannot look up your organizations existing embed secret after it has been created. If you lose your embed secret, you can generate a new one. In this case your existing embeds will be rendered invalid until the API is updated with the new secret.
Steps to Create Embed Secret
Click here to download sigma_application_embed.zip
The zip file contains these two files:
Index.html: the web page that contains the iFrame we are embedding into. No changes are required for this file.
Server.js: a JavaScript routine that sets up the services required and configuration of the Sigma options. We refer to this file as the Parent API.
Open server.js in a text editor and review all the comments (lines starting with "//"). This will give you an understanding of the minimum required parameters to pass to make Embedding work. We will pass more in later sections so it is good to get familiar now.
We have organized the file into sections that have "Required to Change", "Optional to Change" and "Don't Change" values. We will show the entire file for completeness.
Section 1:
All required values, nothing to change.
Section 2:Lines 2A-2H
will need to be changed to match values for your embed.
Read the comments for each item in server.js and it will be clear what the required values are.
For example notice item 2A's EMBED_PATH value is what was generated for my Workbook embed. Also notice that we are using the Finance Team that we created earlier.
The email address and external userID would normally be passed by the Parent Application at runtime after user login but since our Parent application code is hard coded, we will use a unique email for the three Account Types. This matters because when a Creator shares content, the content is owned by the Creator. If you just try to cheat here and use the same email for all three, you will find Viewers have elevated permission in content shared by the Creator.
We want to avoid that in the QuickStart although it is not likely to happen in the real world. It is helpful to understand how things can go awry.
Here are the email addresses we used. You can use the same or make up your own:
embed_viewer@sigmacomputing.com = Viewer
embed_viewer+@sigmacomputing.com = Viewer+
embed_creator@sigmacomputing.com = Creator
We have provided inline comments to guide you through.
Section 3:
All required values, nothing to change in this use case.
You are now ready to start the Node.js Express web server. Use Terminal and navigate to the Public folder where you just modified the two files.
Run the command from the folder where you stored the unzipped download:
supervisor server.js
If you get an error about port 3000 being used already (not typically) you can change the port value in the server.js to use a different port. That is configured in server.js on line 3H
.
Open your browser and navigate to:
http://localhost:3000
You should see the webpage with the Title and the iframe embed below as shown. Notice that Page Controls are available on the Dashboard tab.
The red arrows point to functionality that is allowed to the Account Type we passed in the API, in this case, Viewer. This is very limited but very useful for static dashboards and reports.
We can do only a limited number of things to the Table like sort columns and refresh the data. If we click the folder link shown below, we see that this is the only document you currently have access to and you cannot save a copy. As a Viewer, the page will always look the same to you on each visit.
Clink in the menu in the lower left corner and expand the Workspace folder
. Because we shared the Finance Workspace earlier with the team members, the Viewer has access to it. It is empty for now.
Notice that there is a new user in Sigma, Administration
, People
now as an "Embed User" with the email we set and Viewer Account Type. This was automatically added by the API on first successful access of the Parent application.
So that you are generally familiar with how you might debug the problem we will make an intentional error in our server.js file, see the error and use common web inspection tools to evaluate the request URL that was passed to Sigma.
This is not the only method; just an example you can use if you have an issue in the Embedding QuickStarts.
If you are already experienced in web debugging you can skip this section.
Remove the last value from the ClientID in section 2C. In this case we removed the trailing 2
.
Save the file.
Browse to the site again at:
http://localhost:3000
You will see an error message:
Open your web browser inspector. How to do that varies between browsers so we will demonstrate using Google Chrome.
Hit F12
on your keyboard. This will bring up Chrome's Inspection tool.
Click the Elements tab and look for the node iframe id
, It will be in under the body section as shown below and you may have to click the arrows to expand the body node. Note that you can now see the "src" url and as you hover over it, you can see the entire url.
Right click on the url and click copy link address
.
Paste the url in a text editor. You can also separate each parameter for readability as I have below. In this case, I did not paste the last digit of the ClientID:
Go ahead and fix the ClientID in server.js and save. Check to make sure your embed works again.
But wait, you now can use inspector to grab any Sigma embed url and just use that access the embed right? Let's test that assumption.
With your page working, open Inspector and copy the link url again. This time paste it into a new webpage and hit return.
Notice the error?
URL snooping and reuse is not possible.
We are ready to start working on the second use case, reusing the same content but accessing it with the high level Account Type (Viewer+) we created earlier. We will start moving faster now that you are familiar with the Sigma workflows.
Recall that earlier we shared the Workbook and Dataset with everyone on the Finance Team so now we just want to give users slightly more functionality using the Viewer+ Account Type.
All we need to do is pass the Viewer+ Account Type to Sigma for the user and the additional functionality afforded to that role is unlocked.
Open server.js
and change the values for:
Section 2F:
searchParams += '&:external_user_id=embed_viewer+@sigmacomputing.com';
Section 2H:
searchParams += '&:account_type=Viewer+';
Refresh your webpage.
You will see some additional options available now based on our Account Type settings. For example, the user can send a copy of the Workbook in email and they can also download the data (limited to 1M rows).
This user can also see the Finance Workspace being a member of the Finance Team still:
We are ready to start working on the third use case, reusing the same content but accessing it with the high level Account Type Creator
we created earlier.
Open server.js and change the values for section account_type to creator (2H)
Change the values for email (2E):
searchParams += '&:email=embed_creator@sigmacomputing.com';
Change the value of external_userID (2F):
searchParams += '&:external_user_id=embed_creator@sigmacomputing.com';
Change the value of external_user_team (2G):
searchParams += '&:external_user_team=FinanceCreators';
Change the value of account_type (2H):
searchParams += '&:account_type=Creator';
Refresh your webpage.
You are now looking at the fixed Workbook that will always look this way (or until someone with the rights to change it using the Sigma portal does so).
The big addition here is the Save As button as shown below. This allows the Creator to make a copy, change it and share it with others.
Click the Save As
button and use the modal to navigate to the FinanceViewers folder
. Give the new Workbook a name. We called ours Working Copy for Finance (by Creator)
to be obvious later and click Save
.
The new Workbook is opened in the Embed window. It looks a little different and there is an Edit button in the lower left corner
. Click that.
You are now able to Edit (as Creator) just as if you were working in Sigma's portal. Any changes you publish will be available to anyone who has access to the Finance Workspace.
Let's make some changes.
Add a visualization that suits you. We added a pie chart showing sales by Region. It doesn't really matter, just make some changes that are obvious.
We also added a Title to our Workbook:
Click Save/Publish.
Now change the 4 values in server.js to use the Viewer type, save that change. You may have to review earlier sections of the QuickStart if you have issues doing this:
Refresh your browser page.
Notice that even though you were just working on the new Finance page as Creator
, you are now back to the initial Workbook as Viewer
.
Open the Workspace menu and navigate to the Finance Workspace. You should see the new Workbook that the Creator saved there for users to access. Click to open that and see new shared content:
It is important to understand that there are several ways for users to obtain access to Sigma content based on use case. They are:
Regardless of how the user was registered, they cannot be fully deleted.
Users (from the list above type 1-3) can be deactivated by a Sigma Admin or via the Sigma API at any time.
When deactivating a user who owns some content (they created it) the Admin will be prompted by the Sigma portal to reassign ownership of said content to another user of their choice. This old content will be automatically stored in the new users My Documents / Archived Users folder.
This is an important consideration when embedding content that was created by an account who later leaves the company and their account is deactivated.
There are other QuickStarts that may be based on the configuration and content we created here. Recommend you hold onto what you have created here until you have completed all the Embedding QuickStarts you are interested in.
We embedded Sigma content inside a Node.js web application, passing runtime parameters to configure the embed and demonstrate Account Type use-cases.
Additional Resource Links
Help Center Home
Sigma Community
Sigma Blog