Embedded Analytics with Databricks AI/BI

Summary

This video covers how to embed Databricks AI/BI Dashboards and Genie directly into customer-facing applications using iframe-based, SSO, and external token-based embedding methods.
Embedded analytics enables businesses to monetize data features, differentiate their products, and accelerate time to market without rebuilding analytics infrastructure from scratch.
Databricks AI/BI is well-suited for embedding because it is Lakehouse-native with no per-seat licensing fees, and supports row-level security and multi-tenant data filtering for secure customer deployments.

Embedded Analytics with Databricks AI/BI

We often focus on using Databricks AI/BI to power internal business intelligence, but what about delivering those same insights directly to your customers?
In this hands-on session, you’ll learn how to embed Databricks AI/BI Dashboards and Genie into external, customer-facing applications. Discover how to seamlessly integrate analytics and conversational AI to turn your apps into data-driven experiences that empower users to make informed decisions right within their workflow.
Workshop topics:
-Overview of Embedded Analytics with Databricks AI/BI
-Embedding Dashboards with iframe-based and token-based methods
-Integrating AI/BI Genie using Conversational APIs
Talk By: Doyoung Jung, Solutions Architect, Databricks ; Hyegin Cho, Solutions Architect, Databricks

Chapters

FAQs

What is embedded analytics and why does it matter for businesses?

Embedded analytics integrates data analytics capabilities directly into the business applications users already work in, such as Salesforce or Slack, rather than requiring them to navigate to a separate tool. It allows companies to monetize analytics features, differentiate their product, and deliver insights at the point of decision.

What are the three methods for embedding Databricks AI/BI Dashboards?

Databricks AI/BI supports basic iframe embedding, SSO-based embedding for authenticated users, and external token-based embedding for customer-facing applications. Each method offers different levels of security and user experience depending on the deployment context.

How does row-level security work in embedded Databricks AI/BI?

Row-level security in embedded Databricks AI/BI filters data at the query level based on the identity of the end user or tenant, ensuring each customer only sees their own data. This multi-tenant filtering is enforced via permissions and service principals without requiring separate data copies.

Why is Databricks AI/BI ideal for building embedded analytics into external applications?

Databricks AI/BI is Lakehouse-native, meaning it queries data directly without additional data movement or licensing fees per end user. This video demonstrates how teams can avoid rebuilding analytics infrastructure by embedding existing dashboards and conversational Genie capabilities into their customer-facing applications.

Full transcript

[00:10] All right. How's everyone's morning going? Did everyone go to Chain Smokers concert? >> Fantastic. All right. So, since you guys had fun last night, we're going to have even more fun with embedded analytics uh with AIBI and Genie Space. My name is
[00:24] Hen. I'm solutions architect in digital native space. And joined me with Uh, Duong here. I'm a solicious architect for startups and um, embedded analytics is an area I've been focused on for all my career. To be fair, my career is not
[00:36] that long, but still really excited to share my knowledge with you today. >> Awesome. Let's get started.
[00:49] >> Cool. So, oh, what did I know? For those of you who are not familiar with embedded analytics, what is it? Essentially embedded analytics is integration of data analytics capabilities directly into business application. So the the places that your
[01:02] business users are living and breathing the Salesforce the Slack the one places where they're already at you want to bring those analytics to them instead of having them come to data bricks to open that analytics. So it typically comes
[01:16] down to build versus buy decision. Do you want to spend the most talented engineers time on building the prettiest pie chart and bar chart? Or do you want to utilize the already proven solution
[01:29] and then bring it to those people who want to make decisions off of analytics? And as we see it, typically we see three different um pillars when it comes to
[01:43] unlocking value with embedded analytics. Why would you do it? First and foremost comes to the money monetize. I've seen this many many times. So similar to doang uh pre in my previous life I have
[01:57] worked at a business intelligence company and I would say half of my customers were doing some sort of embedded analytics and it allows them to do some sort of monetization. So they can have like a basic tier with no um no
[02:12] no charge um applied and then they can have a little bit more advanced tier where they would monetize and charge your customers for additional capabilities.
[02:24] Another one is to differentiate. I've also had scenarios where customers will come to me and say hey this kind of capability is not a typical thing within our industry and they wanted to make a
[02:36] differentiation in order to do so they embedded it like dash AIBI dash or they embedded dashboards into their application in order to differentiate in the market and have the customers have a
[02:48] better experience within their platform and as we mentioned time to market. So time to market as we mentioned. Hey, do you want to have your best talented engineers working on pie chart and
[03:00] buyers bar chart or would you want to have rather have them work on the core products that your company is known for? Let's go ahead and let AIBI dashboard do this for you instead of having to spend
[03:12] two months, three months of your developers time creating the prettiest pie chart. With that said, do >> awesome. Uh, thanks agent. And what does all of this look like actually inside of
[03:24] data bricks? So, I'm sure most people in this room today are pretty familiar with AIB dashboards and Genie spaces already. Um, and in most cases, these deployments tend to be pretty straightforward. Uh, but when when it comes to embedding
[03:36] dashboards and Genie spaces outside of the data bricks UI, things can get pretty overwhelming, right? With dashboards, as you can see on the screen, you have three different options from basic embedding to embedding with SSO and external embedding, which all
[03:49] kind of differ in terms of authentication and capabilities. Genie spaces give you even more integration points. Um, going from iframe embedding to uh the conversation APIs to different MCP servers and even
[04:01] using these genaces directly within multi- aent systems. Um, this is overwhelming, but don't worry. The pres the purpose of this presentation is to help you navigate through all these different options. Uh you might also be wondering what are
[04:14] the benefits of doing all of this with data bricks versus somewhere else because you know the reality is there's tons of similar tools out there that allow me to embed dashboards and you know ask questions in natural language that answer my questions. Um but in my perspective there are three main
[04:27] benefits of doing this with data bricks and the first benefit is that this is lakehouse native right like everything else in the lakehouse um you're already using data bricks as your data platform AIBI dashboards and ji spaces already integrate with the tools in the platform
[04:40] that you're already familiar with without having to manage another permissions uh another semantic layer and then another contract which can be a huge headache. So it all comes comes down to the unification story. Uh next it inherits the enterprise ready
[04:52] performance and scalability of data bricks and just by looking at this room um data bricks is used by companies of of all sizes with a proven record for scalability. Um so the same techniques used for caching uh building
[05:04] materialized views client side filtering those things will help you and be applied directly in those embedded dashboards at Genispaces as well. Uh finally and this is perhaps the biggest benefit that I talk to my customers
[05:16] about is that there's no licensing fee with AIBI and Genie spaces. Uh many of you in this industry uh probably know that BI tools tend to charge like a per user or per serving or even like a per embedding license fee licensing fee um
[05:29] just to allow you to publish these contents externally. With data bricks AIB engine spaces you pay exactly for what you use not for the number of seats. So that's a huge differentiator. Um so before jumping into like a deep
[05:41] dive architecture conversation I first of all want to show you a demo of what that actually looks like in real life. All right. So, in this demo, uh, we're all going to pretend like we're the CEOs of
[05:53] a fictional, um, online brick retailer called Brickstore. Um, and in Brickstore, um, sellers and buyers can come and buy and sell different bricks. And, uh, what we're going to do is we're going to log in as one of our users named Carl. And Carl is a brick seller,
[06:08] um, who comes from a company called Apex. So, let's go ahead and log in here. And Carl's going to log into the website, take him to the homepage. And one of the things that Carl wants to do on this website is actually try to figure out how well is this marketplace performing.
[06:22] So we're going to head over to the dashboards tab which is going to load an AIBI dashboard um that is going to be embedded into this website. Notice that I didn't have to leave to another page. It didn't have
[06:35] to authenticate me into data bricks. It didn't take me or redirect me to anywhere else. All the same insights that Carl needs is directly available within the same workflows that he's already used to using. Um and the great part of this is that all the features
[06:47] that you would expect from an AIBI dashboard, right? Um having filters, the different visualization types, KPI visuals, interactivity, drill downs, all those things are natively available as part of the embedded experience.
[07:01] One of the things I want you to notice here is that uh we see that revenue growth has been growing 40% year-over-year, but we're actually seeing that um profit margins, the net margin is only growing by 9%. So, one of
[07:13] the things that Carl wants to do here is try to figure out what might be going on. So, we're going to navigate to the quality and fulfillment tab. And opening up opening up this tab, um Carl can realize that there's a particular product called Castle Fortress 1200 um
[07:27] which has a really high return rate compared compared to all the other um products that are that are out there. Um so, one comes to think maybe this is a reason why um the revenue seems high, but we're actually not seeing the margin
[07:39] um represent that. Um, but the dashboards can really only take you so far, right? Um, one of the things that Carl should also be able to do is ask questions further about this Castle Fortress 1200 product. Um, so what we
[07:51] can do now is go to the Genie tab, uh, which has a chatbot that allows me to ask questions, um, such as, tell me what people are asking or
[08:03] saying about Castle Fortress 1200. And I'm not going to wait for the answer to be generated um since I have the
[08:16] history of um records previous um questions that I've been asking. Um but it gives me a all the reviews that are actually tied with this product and car can see that um there's a lot of negative reviews associated with this
[08:28] specific product. We can ask also ask follow-up questions saying um how does the distribution of review sentiment uh which has been classified by AI classified within data bricks um for this specific product compared to all
[08:40] the other products that Carl hasn't been selling and you can immediately see that there's u unusually high distribution of negative reviews on this product compared to everything else. Um so that supports Carl's um investigation even
[08:52] further. Um so you might also be wondering what happens if another user logs in. Right? So Carl's from this company called Apex, but if a user named Kish from another company logs in, um, he should actually
[09:04] be seeing different data. Um, so let's navigate over to the dashboards tab with Chris's credentials. And you'll notice that the the dashboard layout looks exactly the same, but the
[09:16] actual data within it is actually very different. Navigating over to the quality tab, you see that Castle Fortress 1200 is not a product that Chris sells. Um, so he's not going to see any of that data
[09:28] because the data is actually being filtered depending on who's viewing the data dynamically. Now, with that, I'll pass it back to Hun to um talk about how all this actually works.
[09:44] All right, how is it all looking so far? Oh, how is it all looking so far? Pretty good. I especially like the no licensing fee for sure. All right. So, with that said, I want to
[09:56] dive a little bit deeper into AIBI dashboard. How many of you already have utilized AIBI dashboard before? Could you raise your hand? Okay. Okay. Majority of you. Fantastic. Uh, for
[10:09] purposes of today, we're I'm not going to go in too deep, but I'll show you a little bit more of a high high level overview of the architecture and the um implementation um strategies. And that said, if you want to dive deeper into
[10:22] it, no problem. we can have a separate discussions afterwards. All right. So when it comes to scenarios, there are three main scenarios that are going to come up. Uh for for purposes of today, we're going
[10:34] to be focusing on the external user uh embedding, but we do also have internal user embedding. So option one is basic embedding. uh this is like if you want
[10:46] it to be really quick, you want to get to that embedding uh in minutes instead of couple days or so, it's right there for you. The caveat is that you need to be a data bricks user inside. So if um
[10:59] if a user wants to log in, you will have to go through the login process and embedding with SSO is a is similar situation. The user need to be a user inside data bricks in order for them to
[11:11] be able to do the analytics. But for purposes of today, we want to focus on the external embedding because now we want to talk about how are you going to reveal the analytics that you have to your external customers out there or
[11:25] external audiences out there. So viewers do not have to have data bricks account in this scenario and I think this is a very big advantage. So let's say you have a um company portal and maybe you
[11:38] want to reveal restaurant analytics to restaurant owners and you kind of manage those restaurants. You don't have to create individual um accounts for those people who want to log in just to see
[11:52] their analytics. Custom code is required. However, it's going to be very minimal. And it uses service principle for authentication. Um and you can apply role level security and any kind of authentication method
[12:05] that is necessary as well. All right with that I also want to talk about the design decisions. So permissioning whose permission is is it going to inherit and
[12:18] then also multi-tenency. Typically customers you guys are not going to only serve one customer. You'll likely have multiple customers that you want to serve. So when it comes to permissioning
[12:31] uh there are two options. First is individual uh individual data permission and this is the permissioning that we will suggest that you go with when it comes to external embedding. You don't
[12:43] want to just embed your credential into the dashboard so that whatever agencies everyone can see. Second option is share data permission. Uh that is exactly as it um sounds. Whatever permission that I
[12:57] have, you'll have and the customers will have. This is not the recommended permission uh path for external embedding and multi-tenency. When it comes to uh multi-tenency, you
[13:10] kind of sometimes I see mixture of both. Option one is to have completely separate dashboards for different customers. So certain charts that may make sense for certain customers may not
[13:22] make sense for the other customer, customer B or C or D and so on. That said, there might be some metrics like let's think about like Salesforce metrics. Um pretty much every company that I have worked in cares about
[13:35] opportunities and accounts. Maybe there are some custom fields that you may not care about when it comes to customer uh or company A versus company B. But for those very common metrics, you want to create a common dashboard so that you
[13:48] don't have to duplicate that work. Apply role level security and then roll it out to your end users so that you don't have to create hundred different dashboards when you don't have to.
[14:05] All right. So when it comes to components, what are the steps? This is going to be very high level and we can dive deeper into it in more of a um more of a individual uh sessions and like if you want to talk more about it just
[14:17] reach out to your account team but first and foremost is data is in your catalog. I would hope that at this point majority of you if you're using data bricks have data inside unity catalog. Is that true?
[14:31] Oh fantastic. I like to hear that. And then SQL warehouse. Um I think at this point our SQL warehouse, I think a lot of customers are already utilizing it as well. And if you're using it,
[14:43] please use serverless because it is going to be much better experience. But it is okay if you're using pro or classic as well. It will just be a little bit more degraded experience. So you can see which one works for you.
[14:57] You got to create a dashboard because people if you want to embed a dashboard to your customer and you have to have a report that is going to be embedded. As you can see the first first three steps are going to be pretty much the same as
[15:10] just creating a dashboard inside AIVI dashboard. Now there are a couple additional steps to embed this. First or I guess fourth is going to be creating a service principle. service
[15:22] principle is going to have the necessary permissions in order to run this dashboard, run this query and then um catalog and schema and um table usage in
[15:34] order to render that dashboard. Second, you will have an application back end um access to service principle credentials and data bricks rest API
[15:47] and application front end to have UI to display embedded iframe optional but you can also allow less domain under workspace setting and so on.
[16:00] Simple enough, right? All right, with that said, let's go into architecture. This one may look a little bit daunting, but do not worry. Um, it's
[16:13] not as daunting as it may look. So, when it comes to architecture, there are three key components that we're going to be talking about. There's application layer, authorization layer, and then datab bricks layer. So, end user logs in
[16:25] to front end. Front end sends that to back end. back end is going to check with identity provider to see if that credential is actually legit. Once it is legit and verified, that is going to
[16:38] send back a JSON web token. With that, it's going to go ahead and get um request client ID and secret from secret manager for data brick service principle. But we're not going to directly use that service principle. We
[16:51] want to be a little bit more careful and more secure. So with that we're going to go over to uh data bricks authorization layer to get oath token. With oat token we have um token scope and also
[17:07] a custom claim as well. With that your front end is going to import AIBI library pass in those token ID token and
[17:19] dashboard ID then it's going to apply role level security utilizing external AIBI um user and then once all of that is done with
[17:32] that we're going to just render that dashboard for you with the necessary data that is going to be displayed for the user so that Hun will see only see Han's data. Do will only see Doian's data. We don't want that to be mixed up.
[17:46] >> I just want to pause real quickly here and just clarify that whenever you create the OOTH token, you're actually minting it with um information specific to that user. Um so if Hun's coming from a company called Apex, we're actually
[17:58] passing that Apex information into um the OOTH token as a custom claim. Um so whenever that token is used to now embed the AIBI dashboard um you'll see in the dashboard section that there's actually
[18:10] a wear clause saying customer ID equals AIBI external value and that external value is actually the custom claim that we've passed on during the OOTH of authorization layer and that's kind of how we um ensure that um everyone who
[18:22] sees um the dashboard sees the data that's filtered towards the custom claim that is passed on from the application layer.
[18:34] All right, with that I also I want to finalize a dashboarding piece with one of our customers. So, Snippet uses data bricks embedded AIBI dashboard but puts self self-service analytics directly into
[18:47] customer portal with almost no extra application engineering that they had to do. Uh what what do they embed? uh they embed dashboards for fraud, aggregated, geographic, product usage, ROI, uh bad
[19:00] debt and so on and so forth. Access is handled once at the platform level. Role level security ensures each property or customer only accesses their own data without duplicating dashboards per
[19:12] tenant. And why does it work? Well, well, first and foremost, um all of the data is already inside data bricks. And it only took about a week for them to launch embedded analytics to production.
[19:25] They rolled it out to 200 users and more. And they plan to roll it out to even more users as we go. And what they saw is that 30% higher retention for feature activated accounts. And I think
[19:37] that is extremely huge uh for anybody who is thinking about hey I want to make sure to keep this customer provide them with the more analytics provide them with extra um capabilities and the nice
[19:50] thing no licensing fee with that I'm going to hand it over to do to talk about Genie. >> Awesome. And Snap was actually my customer. Um they went from not having um any embedded analytics. So um they were evaluating a different vendor and
[20:04] decided that it was too cost prohibitive to scale that out to um hundreds and thousands of users. Um and we actually worked with the team to get this enabled um in their environment production environment within a week of time span.
[20:16] So this is not something that takes a long time to stand up. Um this is something that you could quickly test out quickly um add into your existing application stack and then start rolling out as as a product line. Um that being said, let's move on to
[20:28] talk about uh the different ways that you can embed a genie space externally. I'm sure this is a big area of interest for a lot of you. Um especially as agentic um capabilities become very popular within applications. Um Genie
[20:40] can be be the layer that powers all of that. Um as with AI um dashboard embedding uh we need to think about whether the end customers who are going to be consuming these dashboards or Genie spaces will be
[20:52] internal or external users. Um for internal users uh we can use something called iframe embedding. This is basically the same thing as a dashboard basic dashboard embedding. Um essentially you go to um any genie space
[21:05] you want to embed. You copy the iframe code and you paste that into your um application's front end. Um the limitation with this approach again is that the users have to authenticate into data bricks before being able to see uh the embedded genie UI. So it's really
[21:18] suitable for um internal use cases. Maybe you have a sales portal and you want to make Genie available to those users um out of the box. Um this is a really good use case for that. Um some of these other options that we'll talk about right now will give you a lot more
[21:30] flexibility. And the first one is a Genie conversations API. Um and this is a um API layer that gives you programmatic access to the Genie space like um starting a new conversation,
[21:42] continuing an existing conversation. Um this is a much lower level construct that gives you a lot of flexibility. Um but you will also have to do do a bit of coding to make everything work together seamlessly and we are going to dive deeper into this. Um next we have the
[21:54] MCP servers. Um there's currently two flavors to it. There's the uh Genie spaces MCP, there's a Genie 1 MCP. Um and there's slight differences between the two where the Genie spaces MCP server um is tied to a single Genie
[22:06] space. Um it's also stateless in that it actually doesn't preserve conversation history. Um, so if my agent calls the MCP server, ask a question and then tries to ask a follow-up, the Genie MCP server actually doesn't support that.
[22:18] Um, Genie1 MTP is um, directly tied to the Genie1 space. Um, so it has access to all the Genie spaces inside of um, your database workspace. Um, and this one is stateful, which means that you can have ongoing conversations. Um, so
[22:31] those are two different integration patterns um, with the MCP servers. Uh finally we also have customers building their own agent systems using um frameworks like uh DSPI langraph lang chain um and even agent bricks um and in
[22:44] in these cases we have Genie um available as a agent out of the box um and it's basically a highle abstraction of the genie conversation APIs um to make it easy for customers to use instead of having to maybe create their
[22:56] own tools and functions to power that um you probably already noticed but um options three, four and five are just um again high level abstractions of the genie conversations API. Um so for this conversation we're going to focus on um
[23:09] what the APIs are, how they work um and then the different um architecture patterns that we need to think about. All right. So what are the Genie conversation APIs? Um essentially it allows you to call Genie from a REST
[23:21] endpoint instead of having to go through the data bricks UI and this really gives you the flexibility ability to call Genie from anywhere. Uh whether that's your customerf facing application, it could be a team's channel or um anything
[23:33] else. Um, and notice that there's uh five different API endpoints that you can call um starting from the starting a new conversation to um continuing an ex existing conversation to getting the content of the message that Genie
[23:46] generated um to getting the SQL results of um the the generated query and then finally re-executing an existing uh SQL query. I also do want to point out that the um conversation API as of now today
[23:58] supports uh Genie in chat mode. Um if you're a Genie user, you probably know that there's two modes to it right now. There's the Asian mode and the chat mode. Um where the chat mode is better at answering the what questions. So it's good at answering what happened. Um but
[24:10] it's not really good at answering why happened and and you know um reasoning further reasoning beyond that. Um the Asian mode API is coming in private preview uh shortly here. So if that's something you're interested in, definitely reach out to your account teams.
[24:23] All right. So um how does the Genie conversation APIs actually work? Um let's imagine you're building out a chatbot in your application and you want to use these APIs to do that. uh you first want to determine whether the user wants to start a new
[24:36] conversation or whether they're asking a follow-up to an existing conversation. Right? Depending on this uh you would either call the start conversation APIs um which is going to start a net new conversation um and you can see that we're passing in the user's question as
[24:48] the content um as a parameter to that API endpoint. Um or you can call the create new conversation message API which is going to follow up on an existing conversation. And again, notice that you're passing in the content plus the ID of the conversation that you want
[25:01] to follow up on. If that request is successful, um sometimes it is going to fail. Maybe you don't have the right permissions. Um you then need to check the content of the response by calling the get conversation me message API. Um
[25:15] this is because um all these APIs are asynchronous. Um so we do have to implement some kind of polling mechanism to keep checking that the um gener generated response is finalized because genie is an LLM. It's going to take some
[25:27] time to think. Um it does need to iterate through and we do have to implement a polling system within our application layer to do that. Um once generation is complete uh we also have to kind of check that the response contains a SQL query. Um or whether it
[25:41] just contains entirely text. In some cases Genie will respond with a follow-up question instead of generating a SQL. Um so in that case we won't have any uh SQL query generated.
[25:53] In other cases, Genie will actually respond with data. In this case, we need to pull another API endpoint which is the uh get SQL query results to actually retrieve the results of the SQL query and the response that it generated. And
[26:05] once that finishes executing um uh SQL will be passed on to Genie as a final output and then we can um serve that as our final output to um our application layer. The fifth endpoint for
[26:17] re-executing a SQL query can be useful for building cache layers, right? So, um maybe the user is asking similar questions over time and you don't want you need to have to reason and try to figure out which SQL query to use. Um
[26:29] you can have um a supervisor LM basically route that to um re-executing a SQL query that we've already executed in the past. And that's really it. Um we essentially hand you the building blocks
[26:41] to build Genie yourself in your applications. When it comes to design decisions, uh we need to consider permissions and multi-tenency the same way we do for dashboard embedding. Um first you got to
[26:55] decide how to handle permissions. Um and basically um whose permission is a genie space going to use when answering your question. In most cases we would want to use um the permissions of the person or the identity who's actually asking the
[27:08] question or making that request. Um and by default Genie uses um the identity of the person or the identity who's calling um the request. We do have a feature in private preview for embedding credentials which is actually going to
[27:20] use uh the credentials of the author the last author who's um edited that unispace. This could be useful in some cases but for most embedded use cases uh you should go with option one. Uh multi-tenency same discussion with
[27:33] dashboards. Do we create a single genie space um and then have um our different users log in and do role level security to filter the data um or do we actually want to create separate genaces for each of our tenants? And again, that comes
[27:46] down to um what kind of questions your um customers are actually asking. And in real life, it could be a mix of both. Uh you could create these um generalized canned genie spaces that everyone ask questions to. Um and then for some of
[27:58] your um customers who are a little bit more demanding, you could create these custom genie spaces um that could answer specific questions regarding their domain. Uh when it comes to components, again, very similar to dashboard embedding. We
[28:11] need data in Unity catalog. We need a SQL warehouse and we need a genie space that's really good um especially tested because it's going to be external and part of your actual platform and product. We would want to make sure that
[28:23] the genie space is battle tested um and that you've added the benchmarks and the improvements um that that came from it. Steps one, two, and three. Same thing as creating a regular old Genieace. Um but you do have to create a service
[28:36] principle that has access to all these assets similar to dashboard embedding. Um, one difference here is that you will probably want to create u multiple service principles, one for each of your tenants. Um, that's because currently at this stage, um, Genie um, doesn't have
[28:50] the concept of external ids as we saw with dashboard embedding. So, we can't just pass in um, like an additional context saying, "Hey, um, Hun's logged in. Make sure to filter the data um, for HANA." We can't do that right now. Um,
[29:02] so the workaround right now is to create specific service principle for each um, end user. Um, number five, we're going to need an application back end that orchestrate all those different API endpoints
[29:14] together. A front-end UI that has the ability to um take the responses that Genie generated and put it into nice looking tables. Um, one thing to note here is that visualizations are actually not supported uh with the API. So,
[29:27] you're not going to get any graphs or charts out of the box. Um, but this is coming in um private preview, I believe. Don't quote me on that. Um, but that is a feature that the product team is aware of and we are working on it actively.
[29:40] Um, finally, you're going to have to set up row filters in Unity Catalog. Um, this is a layer that is necessary because we're creating separate service principles um for each of our tenants. Uh, we actually have to set up some kind of rowle security function within each
[29:53] of our tables to say, hey, if this service principle is making a request to this table, make sure that we only show them rows that um this service principal has should have access to. And that's kind of how we um um do data
[30:06] permissioning and separate the data depending on who's viewing it. All right. Uh let's look into the embedding architecture. This is going to be pretty similar to what we saw before. Um but essentially user is going to log
[30:19] in. We will retrieve the credentials of the user who's logged in. Um and then we're going to have to figure out which service principle we want to use, right? Because we have multiple service principles. uh depending on who's logged in uh we want to use some kind of
[30:31] mapping database that has a mapping between the service principle and the user um who's logged in. So we get the service in full ID and depending on the ID uh we go to data bricks and say hey
[30:43] give me the um secret ID of the the service principle that I want to use get it back and then make a request to the data bricks authorization server to do uh machine to machine um ooth and generate a token
[30:57] once we have that oath token we're ready to uh make the request to the genie um endpoint um so when the user asks a question we pass that question to the genie conversation API guys. Um along with the OOTH token,
[31:10] we make a request to the SQL warehouse. Um and this is where the role level security policy is actually being applied. Um so depending on the service principle, Unity catalog will apply those role- level security filters. Um
[31:22] filter the data by um the right rules and then pass the data back to Genie um and then we package it all and pass it back to our end user as a final um response. That's really it.
[31:38] Um, awesome. So, this is actually the last slide I have prepared today. Um, and we won't spend too much time on it, but I do want to share that customers like Atlassian are already embedding um, Genie APIs into their products like um, Jira and Atian Robo to power natural
[31:51] language capabilities within the workflows that people are already used to doing, right? So, you could ask questions about your data directly within G um, Jira without having to get those user to navigate to their own database workspaces.
[32:05] Uh so that's it. Um I know that was a lot of information. Um but thank you so much for your time today and we hope you learn how to embed AIBI dashboards and gen spaces externally to your end customers. And we will now open up for questions. Thank you.
[32:17] >> Thank you.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.