Welcome everyone. Thanks for joining. This is Intro to AI Apps and Sigma. Over the next little while, we're going to break down exactly what an AI app is, and more importantly, what it takes to build one that holds up once real users get their hands on it. I'm Bretton Farrell, an analytics consultant at Innerworks. For those of you that may be unfamiliar with what Innerworks is, Sigma has close to two hundred solution integration partners worldwide. And that top tier that they have for their partnership status is elite status, which we happen to be one of their elite partners. We're a global data consulting firm working with companies around the world on their toughest data challenges. We specialize in data analytics and AI, and we partner with the best in class platforms like Sigma, Snowflake, and Databricks to help you build the right solutions for your business. One quick note is that we're actually in the middle of our Sigma September, where we're running four part webinar series this month. This is our first session, and we've got three more coming up all on different topics, all designed to get you up to speed on what's possible with Sigma. Some housekeeping for today's session. This session is actively being recorded, and we'll send out a replay for in your email the next few days. We're going to cover our content first, which should be about thirty five minutes, and then we'll have time for Q and A at the end. So if you have any questions, put your questions in the chat, and we'll answer as many as we can when we do get there. Haley and I will be trading off throughout this presentation, and we've got two live demos for you, so super excited to dive in. But before we move on, I'm gonna hand things over to Haley to briefly introduce herself as well. Hi, everyone. My name is Hayley. I'm an analytics consultant here at InnerWorks. I specialize in Sigma and Databricks work, and I've been supporting a lot of clients recently through their own modern data stack implementation. I'm really excited about what we're seeing with AI applications and Sigma right now, so it'll be awesome to dive into that and show you what's possible today. And with that, I will hand it back off to Breton to give his own intro, and then we'll jump into the content today. Awesome. Thanks, Hailey. Yeah. Like I said, I'm also an analytics consultant. We're both based out of Portland, Oregon. I've been primarily responsible for a lot of migrations here at Innerworks. So, yeah, if you do have any current migrations you're looking at maybe doing, feel free to put that in the chat as well. Let's start off with where we are today. So self-service BI put dashboard building in a lot of people's hands, and that's genuinely a very good thing. Because dashboards are great for KPI monitoring, historical trends, and understanding what happened. And that's not going away, and the point of this webinar is not to talk you out of dashboards. But we want you to help you identify that there is a catch. And as more people build dashboards like the one here on the screen, the actual workflows and decisions of those dashboards that they're supposed to inform often still live somewhere else entirely. This could be something like a Slack thread where the real call gets made, a spreadsheet where someone rebuilds it every by hand every single cycle, a point solution that only one person really has access to. So a dashboard tells you what happened, but it doesn't necessarily capture what you decide to do about it. Let's make that even more concrete with an example that hopefully everyone in the room will recognize revenue forecasting. Your pipeline dashboard is great for showing you what's currently in the pipe, stage by stage totals, historical close rates. But dashboards can remain pretty static, and it doesn't tell you, for example, what next quarter will actually look like. These separate ad hoc conversations happen somewhere else entirely. A lot of times, something like an Excel model or slide deck, someone builds out beforehand right before, like, a forecast call. This is because business users want to assign probabilities to different opportunities, adjust the factors behind those numbers, and compare scenarios side by side. And the dashboard just can't do that. It tells you one version of the truth, not the version that you're actively testing for. An app, however, can hold this all in one place. The scenario, the assumptions, the comparison live against your actual pipeline data. So I'm gonna stop talking for a moment, and we'll actually pull up our very first demo in Sigma. This is actually a demonstration that my desk buddy Austin White has made. It's our pipeline forecasting app. You can see here that this overview tab here appears very much like a typical dashboard. So we have, like, some filters at the top. We have a stacked bar chart here breaking down forecast versus target. On the right side of this screen, we have some KPIs. Down on the bottom left, have forecast versus target broken down by geography. You can see it does have some interactivity like some dashboards do. We can click on east, for example, and it'll filter all the other visuals in the dashboard. But there's no live write back, no, like, actual ad hoc modeling that we're really doing here. It's very much a traditional dashboard. If you wanna actually go into creating some new models, where that comes into play is if we click on create versions in our tab container in Sigma. Again, we see filters at the top, some KPIs. But where things get a little bit more interesting is this table down below. This is an input table where we can see specific opportunities that are being built into our modeling, Things that are considered, that are colored purple, these are things that we're recognizing the revenue for in our pipeline. But let's say for example there's certain opportunities that we know that maybe for whatever reason they're actually falling through. So I can go over to this manual override column, and I can actually go ahead and exclude these from our model. And you can see these then are accounted for up here in the KPIs. We can also do like in a batch exclusion. So if we go over here, I can clear out what I did here and go to Batch Adjustments. And maybe, for example, we know for whatever reason in the month of December, we're not going to do very well. And so I'm just going to select December twenty twenty six, maybe in our northern region or software specifically. Maybe we know we're gonna take some form of hit, so I'm just gonna factor in a negative one million adjustment. And then we can go ahead and create a new version of what we're modeling. So I can go ahead and call this version conservative forecast. And you can see Okay. So it says actually name already used. It's able to check the versions that we've already created. It can see that we've already named a different version there. So since I've already done this example a couple times to others, I'm just gonna go name this something like v eight because I know I haven't typed that high of a version yet. And now we can see the name is available. We can add this version to our model, and now Austin added this really nice animation for the transition when it's going ahead and adding that back to the warehouse, doing that write back. And now we're brought back to this overview screen with our new version that we just created with that adjustment. You can see now that we're ninety four percent to target. Before, I believe we're around one hundred and two percent to target. We can also go over here to the top right to compare and submit, where we can compare against different versions that we've made. Here's the version that we just created. Now in the middle, we can compare that to target. Maybe on the very right, we wanna add in our CRM baseline. So really cool flexibility in terms of editing live the information that we're factoring in to our models. We can compare against different versions. Let's say, for example, I need to now hand off this new version that we made to somebody higher up than me, we can go to this review and submit option. And I can go ahead and I can flag our new version as something I wanna submit and hand off to somebody else. Apps are amazing in comparison to dashboards and where you can really, on an ad hoc way, change around the numbers, model new things all in this one place rather than having to, like, bring this different ad hoc calculation somewhere else. It's all within the same system. I'm gonna hand things off to Haley now, and she's gonna bring us back to our slide deck. Awesome. Thanks, Breton. Yeah. On the next slide, we'll take a look at why that was such a great example to hang a framework on. Because what we just watched is act it meets the exact test of what we use at Interworks. And there are four questions that tell us whether we're building an app or a dashboard. And if all four apply, then we're building an app. And those four tests are input, logic, views, and roles. And starting on the next slide, we will go through the first two. For input, that is where users enter data across specific fields. They're not just filtering or viewing what's already there like they would with the traditional dashboard. And that's exactly what we just saw with Breton and the probability and the scenario assumptions you showcased for us. The second question is logic. There are rules and calculations that run on the input and transform it into an output in real time. You adjust one assumption and the app recalculates the forecast right in front of you, just like we saw. And that forecast doesn't happen in some spreadsheet far away that someone else has to rebuild every quarter. It happens right in front of you in real time. On the next slide, we'll go through views, which is how the output is presented differently depending on who's looking. Maybe you have discrete and distinct screens or pages for each role where each distinct page maybe has custom visibility set based on their role. And that brings us to fourth, which is roles. So different users hold different permissions and they see different functionality. A rep sees only their own deals and they can adjust assumptions only for their own deals. Whereas a sales leader maybe sees the rolled up forecast across the whole team and they can improve the number that actually goes to the board. It's the same app with one source of truth, but has different access with separate pages. And on the next slide, we'll go over why this distinction actually matters in practice. This forecast app we just watched isn't measured by how many times someone opened it. It's measured by whether the team landed on a number they'd actually stand behind. Whereas dashboards track usage, load time, and last viewed date, Apps, on the other hand, they track active users. They encourage feature adoption and they help prevent drop off at critical flows in the process. And these differences that we're talking about today, they aren't just cosmetic ones, but they help create a product that is genuinely used to get the job done. And on the next slide, we'll look at a completely different kind of workflow to showcase this isn't just a sales thing. So we'll take a look at a hiring pipeline triage. Take your hiring dashboard, for instance, which would show how many candidates sit in each stage, the time and state averages, and source breakdowns. But what that dashboard doesn't show you is which candidates deserve a second look. That judgment call happens in email threads, across scattered interview notes, and maybe the recruiter ends up going off of a gut instinct in the end. On the next page, we'll showcase how an app can actually hold those candidate details, in your notes and an AI assistant that summarizes and classifies all in one place with a different view for the recruiter than for the hiring manager. I'll hand it over to Brent to show you. Alright. Thanks, Haley. So now on the screen, can see a another amazing demo that, actually my boss, Rachel, Kaylee, and then Kim created. This shows like a hiring platform. And so up at the top, you can see total active candidates, candidates awaiting interview, and then average days in pipeline. Over here, we can see, like, each candidate and where they sit within the interview process. From the left, you can see, like, resume review. In the very right, we can see all the way to them getting hired. We can actually click on one of these people. So let's click on Mia, for example, and we can see where she sits in the interview process, how many days she's been in that stage, this different random contact information, role she currently has. We can even attach files like this PDF down here of her resume. This is a sample, so it's just like a random resume, but that could be specific to Mia. We can then go ahead and either approve or reject this candidate. I'm going go ahead and click Approve to move Mia from Resume Review now to HR Interview. I can again click View Candidate. And now in this stage you can see it gives us the option to fill a scorecard. So let's go ahead and do that. Let's say that Mia is a great team player, and excellent fit for this role. Let's say she heard about us through the InnerWorks blogs. So we're just right now providing some context around this specific record of information. Let's say she's looking for a salary of ninety thousand dollars and let's mark Mia as a definite Yes. We're going to click Submit. So now that modal form will send that over to our input table right back to the warehouse, and it's been appended to Mia's record. We can now go ahead and click Approve to move her again to that next stage. We can play the role of the technical interviewer for that handoff, fill in another scorecard, and you can see the questions have changed to that specific spot in the interview process. Let's just say, Very technical. Mia would be a great fit. Let's just say, A plus workbook. And again another definite yes. I'm going to submit that. It's going to append a new record to Mia, and we're going to again hit approve. And now we've gotten this modal again that says that she's been moved over to the next interview. Now we can see Mia under the hiring manager interview step. We can click again view candidate, Now you can see something interesting. We even have a summary of how Mia has been doing. Looks like this summary was actually for a different candidate, and so I can go ahead and actually ask specifically for Mia. So I'll go ahead and say, Please summarize Mia and give a recommendation. And so the developers of this dashboard, they provided a system prompt telling the AI chatbot what its responsibility is. And by default, these chatbots, they have access to no data in your workbook. So you actually have to assign what tables this has access to. You can see here that it specifically had access to tables, candidate details, scorecards, and pipeline history. You can even assign actions to this chatbot. So coming back at the summary, you can see the role that this person is applying for, overall who's been moving them forward in the timeline, who has been me. It's auto appended my email. You can see the scorecard feedback that we provided. So definite, highest scores rating. We said that she's a team player. We can also see the technical scorecard that we provided. And so since Mia received this top rating of definitely, it says that she's gotten high praise, and so it recommended advancing to the hiring decision. So overall, I'd say that aligns well with what we've been doing. And so we can go ahead and click Approve. And so this app is a super good example of a lot of different handoffs between different team members and each step in the process being slightly different. And so that's very text and judgment heavy. So it's a great example of just kind of how an AI app can be extremely tailored to whatever kind of handoff process that you have specifically. So at this point now you have seen two very different apps. The Numbers and Scenarios app that was around pipeline forecasting, and a text and judgment heavy app, which was the HR platform. Now these are two very different apps. Every app that you watch is actually built from the same features in Input tables, Layout elements, and Actions. Let's go through each of these, and we'll drop in screenshots so you can see exactly what each of these AI app features look like inside of the Sigma UI. So input tables are governed right back. Users can add or update data alongside your warehouse data under the exact same permissions as the rest of Sigma. You don't need to set up some separate security model to manage this. Common uses are things like forms and surveys, scenario per parameters like the ones you saw in the forecast demo, and status tracking like submitted, reviewed, approved. One very important design decision worth calling out is when you're setting up input tables, it's extremely important to decide whether you're gonna make it append only or overwrite only. Things like append only would be things like, for example, we want some sort of historical. Let's say every single time you update the status, we want to see who was the one that updated it and when it was updated. So we want to see be able to see a history of how that input table changed. Overwrite would be something like if they change the status from unapproved to approved, it would just override that record. And there's no way of seeing that historical record of who changed it, what happened. And so it's definitely important to decide that early on. And while this sounds like something that's very small, this distinction really matters more than it sounds like it should, and we'll definitely come back to this shortly. Layout elements are what turn a workbook into an app instead of just a report. So these are things like containers, tabbed containers, modals, wizard style flows. This is what gives you landing pages, work queues, and step by step flows that you can upload, validate, review, submit. It's also where a lot of the craft is. You have to find that balance of how much insight you show at once and how complex the screen feels to a first time user. So this is really where we build in that hyper app like interactivity. Actions are then where you wire the whole workflow together. These are how we can write back to an input table, trigger navigation, set a control, send a notification in Slack, for example. And also, there's Sigma Sigma's AI chatbot feature, which can also leverage these actions. For example, in that HR hiring platform demo that we showed off, we were primarily using it to summarize candidates' qualifications. However, if we wanted to, we could have had it create that recommendation and actually go ahead and have an action that's triggered that goes ahead and clicks the approval or disapproved button to almost make it more of an automated workflow. So a lot of flexibility in terms of what you can do there. So we've gone over the nuts and bolts, but now I want to hand things back to Haley to talk about the philosophy that ties this all together, because knowing the pieces is not the same as knowing, how to put them all in the right order. Awesome. Thanks, Breton. So before we name the framework, one quick shortcut, if anyone here has a software background, Sigma basically just renamed the parts of model view controller. Input tables are the model. They store the transactions in the state of the process. Layout elements are the view. They present the work and collect the input. And actions are the controller. They trigger state changes in downstream effects. So everything we just talked about in the nuts and bolts section, that wasn't just a list of features. That was MVC just wearing Sigma's name. And on the next slide, Sigma has a recommended design framework for exactly this, and it's called Build. It's made up of five components, business objective, user path, input model, look and feel, and development cycle. Read them as an ordered set of decisions, not just a build sequence. Each one constrains the next, and skipping ahead is the classic way to guarantee a rebuild. The idea is that apps are designed in this order, starting from the business outcome, not the interface. And these are the ones that actually get adopted once real users get their hands on them. On the next slide, we'll go through business objective, which is where you're starting with the outcome, not just the interface. And so here's how to think through it. Pick a leading indicator, something like cycle time or error rate, and then map that to a value category like revenue growth, cost avoidance, or risk avoidance. And with that value, connect it to an actual financial metric. And this is the number that actually gets on a roadmap instead of just saying a nice idea. This is exactly what that four question test from the beginning, input, logic, using roles was really asking, just made more explicit. On the next slide with user path, there are five tests that tell you whether you have a real workflow or just a report wearing a costume. You have questions about actors, tasks, date changes, handoffs, and doneness to consider. This stage and build is similar to the views and roles from earlier, just made more rigorous. And the answer to these questions help you tease out what workflow is really happening and if you have a good use case for an app or if your use case would really be better suited as a report. Neither is wrong, but for an app, what we're looking for are answers here that show us, do we really require input action, and do we really have distinct viewer and role types? If so, then we have an app. On the next slide, we'll go through input model. And we have two decisions to make here when building an app. So think about these decisions deliberately instead of just choosing one at random. First, append or overwrite. Brenton touched on this earlier with input tables. Do we really need an audit trail, approvers, or concurrent rights? If so, then the answer is to append. But if you have small stable parameters with one current value, then the right call is to overwrite. And if you're unsure, default to append. Most processes need the audit trail more often than not, so it's better to be safe than sorry. The second covers a decision we haven't discussed yet, and that's grid edit or form edit. Grid is fast in bulk, but it's more error prone. It's good for pasting in a quarter of cash flows. Form is slower, but it's more assured. It's good for something like a bonus approval. It's worth pointing out that the forecast app we saw earlier, that was Grid Edit since we were adjusting assumptions in bulk. But the hiring app on the other hand was Form Edit whose one candidate decision carried more weight. On the next slide, we'll dive into look and feel, which have four axes that decide the pattern of our app. Most apps mix several, so don't feel like you have just pick one from each access and stick with it. In the top left for single record versus bulk, what we're looking at is we're choosing the input method used by our app, which was again determined by the risk profile of the edit, like we just talked about. For linear versus hub and spoke, we're looking at the user path. Do we have sequential gates or one shared object that everyone hops between? For ambient versus focused, we're considering the UI of our app. Do we use something like drawers or models? And finally, for solo versus multiplayer, ask yourself, is there a handoff that needs a notification? This will determine the layout elements we discussed earlier with the actual decision criteria behind it. And finally, for development cycle, this is the one that's easiest to skip past. But a good app keeps adapting after launch as users find pain points and the data organization matures. The questions here worth asking are what users should test it first and give us early feedback? Who owns it long term? How will success and efficacy actually get measured, not just assumed? And where does AI play into all of this? So finally, to summarize, we'll go through what happens if we skip a letter on the next slide. And this breaks down why it's all worth the extra time upfront. If we don't consider the answer to each of those questions we just went through, we could cost ourselves extra time down the road trying to implement a process or organization that could have just been built in upfront. For example, if we don't consider our input models and we ended up overriding facts instead of appending, we lose that audit trail for good. There's no going back. If we skip validation at data input entry, we inherit bad data forever because it's already in the system before anyone realizes. With look and feel, if you fall into that one big table trap, then maybe you've just recreated a dashboard instead of an app. And for user path, if we choose to model the app off of an old dashboard instead of the transaction that's actually occurring, you know, the part that requires the app, then we'll end up having to rebuild it. So skipping any one of these steps is more than just a style preference, but it's helping us to prevent a rebuild later down the road when we really don't have time to spare. On the next slide, we'll zoom all the way out. So business objective, as a reminder, that was the leading to lagging chain. It was what that four question test from the beginning was really doing. User path were those five questions about actors, tasks, state changes, handoff, and doneness. For input model, we're considering append versus overwrite, grid versus form, which determines how to actually build our input tables. For look and feel, that was that four pattern access, which determines how our layout elements are laid out. And finally, development cycle that ensures our apps do development over time. So to summarize, you didn't just watch a webinar about a framework with two unrelated demos. You watched one worked example of this exact framework twice, and then we showed you what happens if we skip a step. On the next slide. So if you're sold on this and you're wondering where to start, here's the filter we'd recommend. First, look for something repetitive, something that happens daily or weekly, or someone completes the same steps each time. Then find something that needs to keep you in the loop, something where a person makes the final call, but they could use AI and apps to help get them there. And then look for something that's text heavy, somewhere that summarizing, classifying, or explaining actually adds real value instead of just being a nice to have. Both the demos we saw meet all three, which is exactly why they're good candidates to build in the first place. And to recap the entire webinar, there are two things to walk away with today. First, that four question path, input, logic, views, and roles. If all four apply, we're building an app on a dashboard, and that changes how you should be thinking about it from day one. Second was that build framework, business objective, user path, input model, look and feel, and development cycle in that order. Design in that sequence, and you'll end up with something that actually that people actually keep using. And I'll hand it off to Brenton to wrap it up for us today. All right. Thanks, Haley. Before we get into questions, a few places to keep exploring on your own. We highly recommend checking out Sigma Public if you want to try Sigma AI apps yourself with no setup required. Also, there is the Sigma app library that has many pre built app patterns you can learn from directly. And finally, there's the InnerWorks blog, which is actually where a lot of the frameworks that we were walked through today, we stole ideas from. So that's what we got for you today. Great. Sorry, Gabriela. Oh, thanks. Yeah. We'd love to hear from you and what you're building. If you have any questions about the theory of what we talked about today or more practical questions for how to implement this, we're all ears. So we'll open it up for questions now. Thanks, Matthew. Thanks, Matthew. We did drop that link to our blog in the chat. If you wanna check that out, read the blogs that we referenced and stole from to create this webinar or lots of other great content is on our blog. Cool. It looks like, we've covered all the questions today. It looks like there wasn't really anything. Oh, it looks like actually one just came through. What considerations do you find to be important when constructing data models for apps versus dashboards? That's a good question, Matthew. I definitely think it's interesting with apps. A lot of it relies heavily on input tables. And when you rely so heavily on input tables, you have to really make sure you partition things very safely across every single change that you make. And so usually what they what you do is you'll basically create your base input table, and you'll make a small little tweak in that. And then you'll create your base table table. And then you'll have a separate iteration on that table specifically for modals and pop ups that are specific to a specific record. And so I'd say whenever it comes to building an actual app, definitely take into consideration more classic software engineering principles really come more into play when building apps in comparison more heavily than dashboards. Do have anything to add there, Hayley? Yeah. No. I like that a lot. I think in general, if your warehouse doesn't have the data stored in proper medallion architecture with gold level tables, then that's when you would use a data model, and you would create those tables to be in that gold level format. But then since apps and dashboards both require some input and they change based on what the user is doing, anything that requires edits based on the user interaction has to be done in the app or the dashboard. For Teri's question, Teri asked, for the chat part of Sigma, is it leveraging another AI tool, LLM, or is it a Sigma specific AI front end? And, yeah, it's basically an element within the Sigma UI. You can drag and drop it, and it's actually an LLM that's hosted by Sigma. I don't know specifically the model that they actually do use, But basically, it's pretty much all prepackaged, turnkey set up for you. All you do is you provide the system prompt. You say what element it should actually have access to reference in its context. And then also, you can provide actions to give it extra capabilities of actually automating different workflows. Yeah. There is a way too to set up your external model via API key if you desire. And there's something called AI query, which would then you would connect it with your AI provider. Yeah. And then you should also be able to attach MCPs to your Sigma chatbot too, so then they can communicate maybe a different agent somewhere else can communicate with your Sigma chatbot as well. Great. Any last questions? Okay. Well, I think we've covered all the questions for today. Thanks so much for joining us. Just a quick reminder, this session is being recorded, and we'll send you the replay within the next couple of days through your email. And if you have any questions about Sigma or anything else in your data analytics journey, we'd love to help. So please reach out to our team at any time. And if you think of any questions that we didn't get to today, don't hesitate to get in touch. We'll be happy to walk you through anything. So thanks again for your time and we hope to see you at the next webinar. Thank you everyone.