So I am gonna jump in and I'm gonna put an end to the LEGO talk as fun as that was. It is one zero five. So we're gonna go ahead and get started. Thank you everyone for joining. We really appreciate it. And I just want to remind everyone that this webinar is being recorded and everyone who registered will receive a copy in a couple of days along with some additional materials. So with that said, let's do some intros. John. I'm Jonathan Lundin, and I'm a global managed services lead here at Interworks. What that means is that I'm responsible for the development of managed service offerings like Keep Watch and Server Care. And my name is John McKenzie. I am a Solutions Architect here at Interworks. And I am the not John. My name is Amy Finley. I am the Servicare and KeepWatch lead here at Interworks, which basically means that I spend my day to day herding around a group of IT systems engineers and verifying operational processes for both of our KeepWatch and Servicare services. All right, great. Now, let me tell you a little bit about Interworks. So, we are a global BI and IT company headquartered in Stillwater, Oklahoma. We have offices throughout the U. S. And in Europe and Australia as well. We were Tableau's first ever gold partner, a global partner, and we're a recipient of Tableau's Customers for Life Award. And that's an award that recognizes those organizations that help customers get the most out of their Tableau investment. And that really speaks to what we do and why we're doing presentations like this one and why we have programs like KeepWatch. Our goal as an organization is really to make sure our clients can fully leverage the value of their technology investments. Okay, so let's get into it here. At InnerWorks, we've really seen a lot of our clients move towards Tableau Cloud as their primary Tableau environment. And that's happening with existing users who are transitioning from server to cloud and with new users who are just starting their Tableau implementation and choose to go with cloud. And so as we continue to see more organizations adopting Tableau Cloud, it's really critical that they're treating their cloud environment just as they would an on premises server, in that it needs to be reliably up and running twenty four hours a day, three sixty five days a year. So when we say mission critical, what we mean is that a business would fail if the system is compromised or unavailable for an extended period of time. So this webinar, it's really meant to be a high level look at those things you'll need to focus on when Tableau Cloud is mission critical to your organization, and you want to ensure a seamless experience for your Tableau users. More specifically, we're going to cover several critical components to creating that seamless Tableau cloud experience. And those are operations, security, performance, best practices, and something that will be a recurring theme throughout this presentation, Tableau Bridge. And the reason for that is that if you have on premises data and you're using Tableau Cloud, you need to use Tableau Bridge. So we'll be incorporating some helpful tips for Tableau Bridge management throughout the presentation. And now I'm going to go ahead and move things over to Amy to go into some more details around Tableau Cloud operations. Thank you, John. So with your Tableau Cloud operations, there are four primary sectors to look at, which would be license administration, back end component administration, SLA response, and if you're utilizing it, Tableau Bridge installation and management. So we're going to briefly touch on each of those four points, starting with license administration. So in Tableau Cloud, there are several aspects that require their own consideration. One thing we like to consider when administering licenses and site roles to our users is the principle of least privilege. That is to say, a user should only have access to specific data, resources, and to permission level required to complete their given tasks. It is important to make sure that each user is given the appropriate license levels and are not over provisioned. Considerations need to be made for which users and groups are mapped to which license types and making sure that your site administrators are appropriately assigned. And then your site administrators should be aware of each user's access requirements and be able to properly monitor privilege between a user's site license, site role, and content access role. Outside of user access, some other considerations for site administrators to make are things like: Which data connections are associated with mission critical views and dashboards? What processes are in place to monitor those? Who is notified when there is an issue on the backend side? And are stakeholders clearly identified for each vedashboard? And are the site administrators aware of those? Moving on to back end component administration, this area includes several server like technologies that many of us have worked with before for many years in the Tableau context. These are such things as authentication methods such as SAML or SSO, data connections, third party integrations, etc. Some questions you should ask yourself are: Who is responsible for administration of your IDP or SAML provider if that is implemented for Tableau Cloud? Are support and escalations methods clearly identified? Is your SAML SSO configuration well documented? And then who is responsible for the setup, documentation, maintenance, and reconfiguration of all of these different components? How is that documented? Where is this documentation stored and who's responsible for maintaining it as the site changes? Which data connections are associated with mission critical views and dashboards? What processes are placed to monitor those connections and who is notified when there's an issue on the back end side? Do you have a disaster recovery plan? Is one needed for your organization and who's in charge of that? So if you've designated Tableau Cloud as mission critical for your organization, one thing you must consider is tying your support for the solution to a service level agreement. Consider the following scenarios: You experience an issue with Tableau Cloud that prevents an important user from updating a dashboard or view. Your stakeholders need updated data for a big presentation and they're unable to refresh it. An extract fails overnight and results in this results in stale data being presented to a large group of users. You have a user leave the company and their access needs to be revoked pronto. Or you need to set up a new data connection and support a critical analytics flow. In these scenarios, you need to ask yourself, how quickly do you need an expert working towards a resolution? Answering that would give you the starting point for your own SLA terms related to Tableau Cloud. Other questions to ask yourselves are: Are you tracking your issues via time stamped tickets? Are you sufficiently staffed to meet your SLAs? If your analytics team spans multiple geographic theaters, what does your support coverage look like? Do you have an on call schedule in place for site administration? What about escalation for those resources? Who needs to be the technical contact and who should be a business contact? And what about root cause analysis processes do you have in place? Who's in charge of presenting those a postmortem on the issues and to who? The role of a Tableau Cloud administrator wears many hats and needs to be prepared for multiple scenarios. And then finally, if Tableau Bridge is being utilized in your environment, considerations need to be made about installation and then the management of Bridge. The first step towards Tableau Bridge administration is deploying it according to best practices. This is a topic that we cover thoroughly in a six part blog series on the Interworks website, but we'll give you a quick little primer. Tableau has written recommendations for virtual machine provisioning for Tableau Bridge. As it stands today, this is a Windows only operating system support. Sorry, Linux fans. Tableau Bridge will need to be deployed in what is called a service mode on a dedicated purpose built VM. So if you are trying to run Tableau Bridge in a mission critical way on either a shared server or some random person's laptop, consider not doing that. Consider utilizing pooling from day one if the Extract Bridge is performing an associated mission critical analytics payloads. Your installation will require a site administrator account, and you will want to document your deployments thoroughly for whoever's most responsible for Bridge maintenance. And finally, a few things to consider in your Bridge deployment. Consider all lifecycle management aspects of Bridge including monitoring, troubleshooting, business continuity planning, operating system patching and application upgrades, and network adjacency to data sources. Remember that bridge is essentially a relay or a scheduled proxy of data, so all the network caveats that you would expect to apply definitely apply. And also you want to consider security, which I will hand over to John to continue on. Thanks, Amy. Security is a wide ranging topic, but I'm going to focus on three specific areas in the context of Tableau Cloud. We'll start with access control. Access control configuration in Tableau Cloud should not start without first having security definitions to align your access control configurations around. Describe what you need out of your policy in language that does not get into the weeds on a technical terminology because this will make it easier for different parties, whether that's someone in your C level or your InfoSec team, to weigh in. And it also makes sure that your security policies are aligned with your higher level security hierarchy. A plain speak definition of your security policy intentions can then be your north star for the rest of your security for configurations. An example of language that is appropriate at this stage would be our end users in the marketing departments need read access to these specific views. Those views are maintained by our business analytics department. Maintaining easy to understand definitions throughout the lifecycle of Tableau Cloud in your organization also makes it easy to understand and resolve any misalignments. Once you have your security definitions in place, you can configure your site to align with it. Touching on some specifics, proper configuration and maintenance of Tableau Security involves having a firm technical understanding of things like identity providers, SAML, SSO, and a role based access control paradigm. You need to know how it all works because at some point it's going to break or it's going to have issues. And when it does, that's going to have implications for your entire organisation. A near to us example of this is the upcoming MFA enforcement for customers who are using native Tableau authentication. Having these things tracked and having a well communicated plan for how to deal with them in your organization is part of providing what we'd call operational excellence for your Tableau Cloud site administration. I'll close this topic by mentioning the principle of least privilege in the context of one of site administrator roles. A security architect could talk to you for hours about least privilege, but I'll just say if they don't need access, they don't get access. Just as important as getting security permissions right in the first place is periodic auditing. You need to make sure that you are monitoring for non compliance or drift from your initial baseline of security configurations. You need to ask yourself several questions in the context of security auditing. Do you have a written policy covering authentication, user group permission structure, and site administration privileges? Remember that this policy has both plain language and technical configuration outputs. If you do, how often are you auditing your site for compliance with that policy? Who's responsible for performing the audit? What outputs or reports do you get? Who reviews those? Who's responsible, in other words? Are these audits manual or do you have some level of automation to raise potentially urgent events to a responsible party? If you have a security policy but you aren't performing audits periodically in your application and monitoring the configuration, you don't actually have a security policy. You have a security wish list. It's impossible to talk about security in the context of Tableau Cloud without talking about real level security. And to give ourselves back some syllables for Q and A later, I'm going to say RLS from now on. An in-depth discussion is probably the subject of its own webinar, but at a high level RLS provides user and group specific filter options for data that apply to any view where the data exists. A practical example of using this would be making payroll data that exists in your Tableau environment only visible to parties who are authorized to see it. Remember when I talked about least for before? This is part of that. In the context of site administration, the most important things to remember with RLS include thoroughly documenting your use case for RLS and how it has been implemented. Remember to include RLS in your conversational security definitions as well. Ensure that all stakeholders within the business have been identified for each use case in RLS and consulted on how it should be implemented. Incorporate your RLS configuration into routine security audits. I'll close this section by saying that there are user attribute functions that are being introduced in Tableau this year. If you didn't know, we'll have the ability soon to filter with RLS further with attributes other than user or group memberships. It has a lot of potential utility in the context of Tableau site security. But the thing that you need to make sure to do is ask yourself whether or not additional filtering options actually align with your security policy. Just because you can do it doesn't mean you should do it. So it needs to be a conversation as that rolls out this year. And with that, I'm going to hand it back to Amy to talk about Tableau Cloud performance and reliability. Gladly. So just because Tableau Cloud is a software as a service solution, that doesn't mean you need to just roll it out, ignore it completely, and not monitor anything ever again. So with that, there are two built in tools for site administrators, one of which is the admin views and the other one is the admin insights. So with admin views, those provide information associated with the back end of Tableau Cloud, such as bridge related traffic, extract tasks other background tasks licensing usage, and also data quality warning history. On the other hand, Admin Insights is a customizable providing information more commonly associated with the front end of Tableau Cloud. There are many possible use cases for Insights, but the Starter Dashboard provides a nice spread for you to get acclimated and explore your own implementation. Admin Insights comes with specific views around user and group drill downs, login activity, traffic and adoption, publish event history, sale content tracking, and space usage. So how do you utilize the built in site monitoring resources in Tableau Cloud in a mission critical deployment? And this will vary a lot depending on your organization. But I think that there are a couple of questions that you should ask yourselves no matter what, whether you're a large organization, small organization, all across the board. And that is that is the monitoring paradigm and the requirements well documented? Who is required or who is responsible for your monitoring? Are automations being utilized? Are they in play to assist with your monitoring? And who are the stakeholders that need to be notified when specific issues arise? And then outside of the site monitoring resources, there are additional performance considerations to be made if Tableau Bridge is being utilized as well. The resources provisioned for Tableau Bridge deployments should exceed concurrency requirements for your extract schedule. What does this mean? In simpler terms, make sure that you have enough computing resources and storage space assigned to Tableau Bridge to meet all of your needs. Also understand that your needs are going to change over time. So while what was originally allocated for your Tableau Bridge deployment might have previously sufficed, know that these needs may grow with your user base, data sources, and total bridge rollout. You should be sure to implement pooling in your Tableau Bridge deployment. Pooling simply refers to Tableau Bridge instances that have been configured to work together to log balance extract schedules, similar conceptually to an active active deployment. The golden rule for pooling for Tableau Bridge is the N plus one redundancy, especially if your extracts support mission critical dashboards and views. N plus one refers to the number of bridge instances that you need to support your extract concurrency in your bridge configuration. So for each of those instances you require, N, you should have at least one more instance of bridge than that, plus one. There are several specific, more specific pooling considerations in your site if your site has Bridge supported data sources that aren't all located in proximity to each other. Remember that Bridge is essentially a proxy, so things like network throughput, latency, etc. Can make a big difference in your outcomes. Advanced configurations involving multiple pools, whitelists, and so on may come into play for different organizations. And then all of this needs to be monitored in real time. So you need to be asking yourself the same questions. Who is monitoring your bridge instances? What metrics and other criteria are encompassed in the monitoring scheme? What technologies are used to monitor? And what happens when the monitoring solution generates an alert? Who sees it? How? And when? What are their responsibilities? And do they have access to the bridge instances in the event that hands on work is required to remediate? Or do they need to go escalate the problem to someone else? And in which case, to whom? Finally, we'll move back to John for best practices in your cloud deployments. John. Thanks Amy. We debated calling this section miscellaneous but I think best practices sounds better, right? I'm going to touch on-site structure and governance, and then I'm going to close out our presentation with a few final tips on Tableau Bridge. The topic of data governance and site structure is wide ranging and has many potential outputs. But in the context of site administration, it's important to understand that in mission critical implementations of Tableau Cloud, critical views and dashboards should be maintained with development to production workflows in mind. The production dashboard should be treated like products, not playgrounds. Just like you would do with any other in your organization that relies on changes that affect the output should be implemented in a test environment first, run through all the normal QA and user acceptance testing methodologies that you'd use for anything else, and then finally roll to production. Rollback options should be documented and occasionally tested as well. When you're thinking about site structure and organisation, there are some key questions that you should ask yourself: What are your use cases for Tableau Cloud in your organisation that make it mission critical in the first place? What types of views and dashboards are most important? And who creates and maintains those and who consumes them? What is the range of consequences if the end users of your analytics platform consume incomplete, inconcise, or simply bad data? Topic change. Now we're going to talk about some data source requirements in Tableau Bridge. There are some things you should keep in mind around data sources when implementing and maintaining Bridge in your organization. First, you should understand the general data sources that Bridge is intended to bridge to Tableau Cloud. A general maxim to keep in mind with Bridge is that it only keeps data fresh from published data sources it will not keep data fresh from embedded data sources. That means that in a mission critical implementation of Bridge refreshed data sources you must create data connections that can be utilised by multiple workbooks even if it will only be used by one. If you embed the data source in a workbook, it will not refresh via Bridge. Embedded data sources, just for what it's worth, are also sometimes the subject of frustration in the field of data governance, so following this rule of thumb has the incidental effect of reducing those restorations. A quick reminder on data types as well: There are several data types that must be published as extracts which include file based data, Google Cloud SQL, statistical files, Snowflake when utilized with virtual connections. And then data types that support extracts or live connections include data hosted in private cloud platforms or relational databases such as SQL Server. Finally, I have a quick note around refresh extracts in Tableau Bridge. If you have been in Tableau Cloud for a while and already have a Tableau Bridge implementation, you may still be using what are now called legacy schedules. This model has been replaced by online schedules which are feature complete with legacy schedules. You cannot take advantage of modern bridge features such as pooling with legacy schedules in place, so that is a good reason by itself to migrate to online schedules. We don't know when Tableau is going to remove support for legacy schedules, but we do know that they will. So it's good to stay ahead of that if possible and migrate to online schedules if you haven't already. Back to you, John. Back to me, yes. Thank you. So let's go ahead and do a quick recap of the things we've covered. If you're to just take one thing from this presentation, it's really that Tableau Cloud should be treated with the same level of support you would give to an on premises server. Right? And when your Tableau Cloud is mission critical, meaning that if it were to suffer significant downtime, it could cause your business to fail, You need to make sure you are on top of those things that we covered. So that's the operations, security, performance, the best practices, and of course Tableau Bridge. Now there's a lot right there, right? And this presentation was really just that thirty thousand foot view, and we're going to point you to some more detailed resources in just a minute here. But everything that Amy and Jonathan just went over, those are exactly why we created KeepWatch for Tableau Cloud. We understand it's a lot to stay on top of, and having a seamless Tableau Cloud experience isn't magic. It really requires a strategically planned approach that is continuously executed. And so the reality is that not everybody's going to either want to do that or be able to do it themselves. So if while Amy and John were talking, you thought to yourself at any point, I didn't know I needed to do this, or I really don't want to be responsible for all of these things, or maybe just, wow, we really can't do that. We don't have the resources in terms of the staffing or the time. That's why we made Keep Watch for Tableau Cloud. You're the folks we made it for. That's why we gave it this nice logo. There we go. So with that, we're gonna get to questions in just a few minutes, but I would like to point you to some resources. Have a bunch of resources on our blog. You probably already know that, but in particular, a couple of our colleagues just wrapped up a six part blog series on Tableau Bridge. So if you're looking for a deep dive on that topic, you can find it there. And of course, if you're interested in keep watch for Tableau Cloud, you can go ahead and reach out to us. You can see the link there for our contact. And if you do go and search on our blog and want more information about cloud or bridge or governance, you can just search for those things in the blog and there's a ton of information there. You may have noticed a few polls come up during this presentation. I'm gonna add one more right now. I'm gonna close the one we've currently got. And let me just launch this next question. And if you go ahead and answer that, that'd be great. We'd appreciate it. But other than that, I'm going to hand things over to Amy so she can kick off our Q and A. Amy? Gladly. Alright. I see that we have one question in the Q and A so far. So we'll just go ahead and get started with that one. The question states, We heavily rely on pulling metadata from the backend Postgres SQL, Postgres Workbook metadata database for Tableau Server. Have you found that the admin insight supplied dashboards, are they adequate compared to having full query access? And to answer your question, I'll go ahead and take this one unless you guys want to chime in. No, I got it. Cool. Okay, cool. Go for it. As far as I've worked with them, the admin insights dashboards and well, all the built in dashboards, they are adequate. They're useful for, I think, new new Tableau Bridge administrators. They are nowhere near as in-depth as the Tableau server ones. So that is a big change. And the reason for that is that the insights just doesn't don't have all of the tables that are listed in the git git dictionary, which is why primarily Tableau Server has more of the deeper, deeper analytical dives, which is a very long winded way to say they are in comparison, but they are, if you are really into using the Tableau Server, built in dashboards, admin views, Postgres, like pulling your Postgres data and then building out your own Tableau dashboards based on that. I it's not going to be as comparable and as customizable, but it is simpler in general and also, would say, yeah, adequate. Good for what the application is. Hey, John and Amy, I'm curious if you wanted to just maybe give a little bit of a more detailed description of how KeepWatch for Tableau Cloud came to be, like how and why. I know I touched on it a little bit, but I think it'd be great to just hear a little more of the scenario around it. Yeah, I'm happy to talk about that. Just for context, I'm not just a Tableau person at Interworks. I work with all kinds of IT technologies. I've been here for a while and I was part of the team that participated in a lot of the exchange to Microsoft three sixty five migrations back whenever that was at its heights. So I've been through this before where, you know, a major a major platform for customers has gone from having a focus on on premise solutions to a focus on cloud solutions. And so what we found as we went through this was our customers, their needs changed. They didn't go away. They just changed from, you know, a primary focus on maintaining servers to a primary focus on maintaining service. And so whenever we started working on the KeepWatch product, and again, we're Amy and I are both in server care every day. So we spend most of our days thinking about Tableau Server. So KeepWatch was born from that, that understanding that the needs will continue. We're going to need to continue supporting our customers in the cloud and it's just going to look a little different. All right. Looks like we've got a couple more questions. The top one says, We currently use Tableau Bridge, but we find monitoring extracts while they are running to be difficult. What solutions does keep watch out for that? I'll hand this one to John most likely. Yeah, so the native monitoring is obviously it's not necessarily sufficient. So we utilize a third party solution and webhooks for extract monitoring. I will say it is also not perfect. I think that there are some there are some things that will improve down the road in terms of the back end in terms of getting better outputs while the job is mid progress. But there are some things you can do with webhooks that make extract monitoring a little bit easier. They just require bringing in third party solutions. To add on to that as well, while it's actually running is very difficult, because the main mechanism you have to actually keep an eye on that is specifically network monitoring for throughput. One thing that's nice about a service such as KeepWatch is that when that does fail, if that does fail, we would then go into the logs, Windows Event Devers, all of the different areas where failures are recorded and then troubleshoot why it failed and go from that different direction. So the monitoring solutions that John was talking about can give us insight on like network throughput issues or if CPU or memory are maxing out. Those alerts kind of give us a clue that, Hey, something's going on. We should jump in and check this out, and we get those alerts live. And I think we have one more question coming in there. Amy, you want to grab it or or John? Yeah. So this one states in considering a migration to Tableau Cloud from on premise, anything on feature parity or guest access or moving from a multi site instance, capacity limits, etc. Can we support twenty ks users? I can start on that one. So one important thing is that your Tableau cloud account is going to equal one site. So if you're merging multiple sites, you're going to have be strategic about how content would be organized into that one single cloud site. You can either pay Tableau to get more than one site or well, so if you pay Tableau to get more than one site, those are not actually related. So if you're like switching between site to site to site, it's not as simple as it would be with like on prem or server. And then on, let's see, guest access from that one, I don't think guest access exists anymore. At least not in Tableau Cloud. I think you have to have a license specifically unless you already have embedded core licenses. Then maybe. On the subject of capacity limits, So there are there are not like say you can support as many users as you want theoretically but just keep in mind that there are hard requirements on the amount of content that you can store in given site. It's one hundred gigs for a normal Tableau site and then it's up to a terabyte if you have advanced management. And then there are also limits that you can kind of push up against if you start having a lot of heavy utilization on a single site. So Amy was describing a multi site to multi site paradigm and that might be a better fit depending on what your traffic looks like. Yeah, a lot of it would get into really specific company needs. One thing you might consider doing is you can either reach out to John, John, or I after this, and we can kind of chat through what we've seen historically and ask more specific questions. Alternatively, on the Interworks website, I think written by Tony Kah, is a full blog post on the considerations that need to be made in moving from Tableau Cloud to Tableau Server. I can probably go try to find that while I'm answering questions. So I can post that here in the Slack in just a second. In the meantime, we have another question that says what's pricing for Keepwatch? And that one is definitely John. Yeah, mean the answer is really it depends. We price KeepWatch on a per site basis and we have a couple of different we have a couple of different options in terms of features depending on whether you need tablet bridge support or not. So I would say the best answer there is that we do have a contact form. And so if you want to get in touch with our reps, we can get a conversation struck up with you and begin to size that. Right. I don't see any more questions coming in. I maybe give it just another few seconds here. If anybody wants to get another question, go ahead and type it real quick and we'll get to it. Otherwise, we can give everybody back some time, which I know folks appreciate. And I'd just like to once again thank everybody for coming. Thank John. And I want to special thanks to Amy because she jumped in to this presentation last minute. So, I really appreciate that, Amy. Thank you so much. And of course, thanks again to everybody for joining. With that, I don't see any more questions, so I think I'm going to call it here. And I have the authority to shut this whole thing down. So I'm gonna go ahead and do that. Everybody have a good day and once again Bye everyone.