okay hello everyone uh good morning good afternoon good evening uh Welcome to our modern change Academy Series so this is a new series uh we kicked off a couple weeks ago so this is the second session um there going to be varying sessions that cover different topics uh spanning multiple products so we have change management digital product release and devops change velocity so we'll be doing these sessions the fourth Thursday of every month um for the foreseeable future um and once you subscribe to the series you no longer have to subscribe to the individual events so you'll automatically be invited to all of them and you can join whichever ones are relevant to you so today uh we're going to be covering shifting compliance left so how to integrate DPR policies with irm we have Joe offenberg here to speak uh Joe I'll let you introduce yourself um and with that let's uh kick it let's jump in yeah hi everybody thanks for joining uh my name is Joe offenberg I'm an outbound product manager in our itsm business unit and I focus on mostly devops and devops change velocity and digital product release uh thank you for joining what we have today is a really great session on the very much a modern governance session on how we tie uh the policies that we have in digital product release that take place at the different phases of a release uh we're going to show you how we can tie those policies to irm compliance uh control objectives okay so I'll go ahead and get started uh we might make some forward looking statements about future capabilities so this is a a safe place to do that without uh incurring any uh uh legal uh implications around that so also Joe real quick real quick before you jump in we do have a Q&A for this session so if anyone has questions please just post them in the uh Q&A and we will uh get those answered uh Joe will stop periodically to answer some of these live so please just post them in the Q&A section as they come up thanks yeah thanks Greg uh yeah so so uh when we talk about the policies that we have in the release phases and as part of the release process uh these policies typically they don't live in a in in a vacuum they're not just for the benefit of application development uh although some of them are right some of them are to make sure that we're following uh development best practices and the best practices of application development teams but many of them are actually uh dictated by risk Frameworks that exist at a much higher level and exist across the entire uh company and in some cases across the entire geographical region and these could be things like uh cobit or ISO 27,000 uh compliance regulations uh in Europe you have gdpr regulations so there's quite a few of these Frameworks that have implications uh for all the different workflows we have in service now but very much so around the release of new software and new digital products right and and also the release process in general so what we're going to do is we're going to show you how not only can we apply policies during the release process and and those policies themselves are very valuable in automating a lot of what's required but those policies could actually uh be reflected in the status of compliance at a corporate level for these Frameworks and that's and that's extremely valuable there are a lot of different um personas involved in this process so let's take a look at them uh the Enterprise architect right they're uh they're responsible often around the tooling and the connectivity between the various platforms and also uh what the process that the developers use in the implementation of devops and so on often they have to uh prepare these audit reports on how well teams are following those processes and many cases it's it's a it's a manual process right they have to uh often dive into each team's release and see if if the correct steps were followed uh many times they're they're required to attest which is a manual step basically they'll get email they have to check a box they have to attest to the fact that okay a security scan was done or a a certain um type of test was done in the release process uh and that's simply just a check of a box that that that a human does and and and it's not always accurate and it doesn't always meet the compliance requirements so what we've do with the digital product releases we actually have checks on the actual data that make up the results of that uh of that test so if you run a security scan in your pipeline we can get the results and this is uh this is a very valuable time saer not only for the architect but also the developers right they're they're making all the changes they're making changes they're committing it to get repositories a lot of those changes are susceptible to these type of policy checks and we want to make sure that as we increase compliance we're not also increasing the burden on these Developers okay and then of course the compliance managers and often these folks are uh you know in a different organization in a different part of the world sometimes and and and they have to understand what's happening within uh these autonomous development teams who are very much no longer part of it anymore right if you've seen any of our presentations on digital product release one of the reasons we created that solution was to provide governance around these autonomous teams which have moved closer to the business units and away from it however the compliance responsibility still belongs under the it organization or under a compliance organization that's part of centralized governance and they have to be able to capture what's happening across many different application teams in some case thousands of different applications uh across the world and roll that up to whether things are you know they're following these uh control objectives and and these compliance Frameworks okay and that's why this is important and I'm going to show you exactly how we can take uh all the different things that are happening in the devops pipelines in the release uh pipelines and roll that up to these compliance checks okay so we have a lot of customers uh that have come to us over the years and say hey this is a problem they've been trying to solve uh auditing is is a big part of what it organizations do and the and it's not not just uh it's a function at every level right so you might have a compliance manager that's constantly uh being approached by internal Auditors or sometimes third-party Oran auditing uh organizations like consulting firms that come in and audit and we have to provide uh the data that shows that that they're in compliance and the uh other customers we've had over the years such as uh DMV is a great example they uh they under undergo multiple audits a year they have 2800 control objectives they must ensure compliance and each one of those control objectives can have you know hundreds of controls specific things that have to be checked so you know the numbers are are you know astronomical when you look at it across a whole organizations and and and as far as developers the developer productivity uh can can be impacted by this right because the burden on develop to actually document things that they're doing even if they're being done in an automated way but to still uh account for that in a comprehensive uh aggregation of all the changes they're making can be really uh quite a bit so you know we want to reduce that uh administrative burden on the developers as well and on the application teams and give them some more time to develop software and create fixes and enement requests okay so where does this fit into the uh irm product well if we look at the solution here um I'll take you through you know step by step so uh the risk example that I have here is you might have uh a data breaches or financial penalties because you're not following certain procedures uh at the software development team level right and this could include using expired libraries or you know a few years ago we had the log forj issue and we had to figure out which application which modules had this version of log forj that had these vulnerabilities and it was a it at the development level it may have been something that's already been addressed but how do you prove it how do you how do you prove it at the compliance level that you're no longer using these log for J libraries right so we have the ways the mechanisms to do that we have also software quality checks and there are tools that developers use and they have this under control right they have this in their pipelines and very clearly they can see right a development team can see by looking at their Jenkins pipeline or the Ado pipeline hey the the software quality scan was perfect it looks good everything's great and one indiv individual team might be able to prove that very easily but how do you prove that at the Enterprise level how do you approve that at the organization level you need to roll this data up and that's what I'm going to show you how we do so in this example you might have a a control that says software quality scan on all software changes so anytime you make a change to software you have to run the scan tool again and in the case of many of our customers they use something like sonar Cube or uh they might do a security scan with check marks or beur right and that's happening in their pipeline so those results become very important we want to uh we want to be able to to show that those things are happening at every level of the organization uh and then there's also the requirement not just to show that you're in compliance but handling exceptions and this is where irm comes in uh because irm is the is the top- down tool for looking at the compliance dashboard looking at specific Frameworks under those Frameworks looking at specific controls right so you have this hierarchical model and then those controls uh determining um which ones are in compliance or not but then there's another very important aspect of this and that's the exception process we always have exceptions to these controls right maybe for one reason or another you might say okay for this particular product the risk is very low we're going to allow this exception this one time maybe for a 10day period to to deploy these changes into production without meeting this control so you have to be able to not only track compliance but track the exceptions as well and very much this is a preventative uh control preventative mechanism M keeping bad code out of production but also keeping um the compliance team from incurring fines and and and uh you know legal liabilities for these type of things uh being part of the product uh and we've seen you know the headlines over and over again where where there is a uh a data breach or some type of uh other you know a change gets released into the environment and you know very recently we saw this with crowd strike uh you know thousands of customers are impacted and it has huge implications right so uh one prevent it from happening and then number two prove that You' prevented it from happening is is really what it's all about okay so how are we doing this well as part of um digital product release we're using a technology that's actually been around for a few years in the service now platform and that's called the policy is code engine the policy is code engine is integrated with irm even before digital product release uh was created to use it it was integrated with irm for the purposes of uh providing uh the the policies that roll up to these uh these these controls right so from a digital product release the fact that we're using the policy as code engine is all we have to do to make this integration work now in the in the next release of digital product release so in the November release that comes out we will have all the documentation necessary so that you could Implement what I'm about to show you uh but the but the the core engine that makes this happen is called the policy is code engine or what we call it as Pace okay so you decide as a release manager these are the policies I might want for various aspects of my release so maybe in the development process we want to make sure that the uh the builds are successful we want to make sure that the um the teams followed best practices as as far as controls around their git repositories make sure Branch protection is enabled in the git repo these are the kind of things that are happening like at a development phase maybe as a packaging phase we want to make sure that there's legal sign off there's documentation has been reviewed there's uh there's nothing that's uh like a copyright infringement and so on and so forth these are the kind of things that are happening in the release pipeline in the release uh process and then um we're going to have policies around that to control that and I'll show you how that works in a minute so we we have these uh policies integrated into the application uh we have the data associated with the policy and this rolls up the pace and this makes its way into the uh control objective and this speeds things up quite a bit it's a lot less time spent on the audit process and the compliance process on both sides the Auditors spend less time on it and the development and application teams are spending less time on it as well okay so at this point I'm going to switch over to a live environment and I'm just going to show you first uh what I mean by bringing these policies into the release process so in digital product release there there are really two aspects to it if you've seen any of the previous presentations on digital product release you'll understand that one Persona that's responsible for uh the best practices and for creating release templates is really part of the it organization uh they manage the release process this is done by uh in our case it'll be our release ad administrator Andrew Jackson okay Andrew is gonna I'm going to show you they create templates and the templates are used by these autonomous application teams that are that are parts of different business units right and what do these templates look like well a template is simply the phases of a release okay and then within those phases the different stages of a release so this is a major release template this might be used by an application development team uh you might have releases that do infrastructure infrastructure is code you might have releases that do patches and so forth uh So within that release we have uh tasks that get assigned to people and but we also have policies and both of those are part of the phases of a release so if I drill into this particular template I'll see that okay there are six phases there's a planning phase a development phase packaging phase user acceptance and validation then we then finally we we we deploy it right to production uh but typically at each one of these stages you're going to have different tasks that get manually uh um executed by different individuals but also the policies and that's what we're talking about today are the policies so for each of these phases I'll show you what those policies might look like like uh in the planning phase you want to make sure that all the stories are planned or all the approval tasks are complete for planning and in development phase you're going to have a lot of testing going on and a lot of uh build results that you could analyze a lot of stories and things that need to be complete code coverage software quality compliance this is happening in the development phase these policies are all part of the policy is code engine that means we don't have a human uh ensuring that the policy is is executing we have the policy is code engine uring and basically the policy is code engine uses uh code in in most cases it's JavaScript but we also have low code ways to do this where you simply uh have drop- down lists and and and values and things I could show you that that make their way uh into these um into these phases of the release right so these are the policies that we want to roll up for compliance purposes uh in the um in the compliance workspace okay uh I think maybe this is a good place to stop and just to see if we have any questions if if this is all making sense to everybody yeah Joe we had a question this is a bit more broad so I don't know if you want to answer now or answer a little bit later but from Carla Smith we have how is the change management process managed within a release yeah can come back to that at the end but that is a good question yeah so that's um you know the release the change management process is typically part of the deployment phase of a release and then if when when we when I show you a release I could drill in and show you the changes uh associated with that release okay are there any other questions uh we have one from Lori Conaway do you use release templates instead of uh change requests yeah the two things are actually independent of each other so when we talk about release templates uh these are basically governing all the phases and the tasks and policies associated with a release however if you look at the common Services data model right you understand that there are build and planning uh Records in in in service now but then there are also the uh running environments right the Planning and Building of releases is happening all on the build and planning side of the csdm model when we deploy something to production then we need a change record okay so that's usually one of the stages of the uh like the uh one of the tasks in the deployment process would be to uh submit a change record as part of that deployment for each instance of that version of the release that you're deploying okay so that's really how those two things are uh tying together when're not replacing one with the other uh release management is all about getting versions of software ready for release and these uh the changes are about now taking a version of that software that's already been deemed ready by the release process and deploying it to uh a CI in the cmdb an application service or a business service and so on that's that's good and and I'll show you examples of that in a few minutes okay and any other questions about release templates there there's a follow on uh would there be multiple changes that will from that release or one single change you could have multiple changes in fact Let Me Go show you that now because that'll transition us into the next aspect of this so I'm going to go ahead and um impersonate let's say a product owner the product owner is responsible for multiple releases of multiple products and I'm going to show you how the execution of this template will play out okay so as a product owner uh they might be responsible also for the scoping of release that means making sure that the the correct features are being delivered in uh each release um and that means the um you know integration with tools like jira or tools like Azure devops uh are going to be important uh so when we bring up the you know what I'm going to I'm going to end the impersonation I'm going to do this as myself that'll smooth things along here when we bring up the uh the the What's called the release planning dashboard and I'll bring it up for that particular release um here we go uh you'll see that that there are various versions of release and each one of these is releasing a version of the product right in this case it's the 4.0 release I'm going to drill into that release as part of the execution that release we are deploying changes and if we deploy those changes to production we will need change records and as you see here there are multiple change records in this case we have multiple change records for different builds and they are impacting these various environments in this case we we only open changes for production so these are all production environments but let's say you're deploying you know uh the same build to a Tokyo production environment and then another one to a production environment in New York you're going to need two different change records because those are two different application Services two different CIS even if it's the same software version does that answer the question of of the relationship between release and change okay great um okay now to move on as part of this release execution we are also looking at not all are the tasks complete or what the status of the tasks are but what are the what's the status of the policies right and as I mentioned before these policies are scripts that are executing right using the policy's code engine to see if we're compliant to see if the testing was complete if if if all the uh the smoke test complete software quality compliance and so on happens and when something doesn't happen uh correctly it's going to show up as non-compliant right because here we see we have some critical vulnerabilities for example or software might not be in compliance these are the things that roll up to those control objectives in the compliance workspace right I'm going to go ahead and show you an example of this I'm here in a GitHub uh pipeline I'm going to create another version of this autofact okay using GitHub so assume that a developer has made some code changes and now they're going to go and create another build of that we want to see if that one is in compliance when that build completes as part of that build process and we'll drill in here you see we're running a sonr cube scan and we're publishing all the test results and making them available once that happens service now is able to pick up that data okay so if you're familiar with digital product release and I encourage you to to look at some of the other videos that are posted online or go to the webinars you'll know that we are using the same devops data model that devops change velocity uses so all the data that's happening in these pipelines is available to us for compliance checks okay so when that complete uh we'll see the the the current version of this um of this build uh we can see the test results down here are in compliance so so 12 tests uh executed and none of them failed that basically maps to our reading of this as well so here we see the 12 test passed and none of them fail that data coming from the pipeline makes its way into the release process we know when the development phase is complete because all these stages will be compliant okay but from an Enterprise level how are we ensuring that all the different application teams and all the different releases that are going on are also in compliant right because as a compliance officer I'm not really so concerned with one individual uh compliance check that's happening in one version of one piece of software in the environment I want to make sure anything going to production is meeting that same check okay so when this uh pipeline finishes and let's see if we have a new build yet we should have just about ready uh to uh complete this um I'll see that this check this this this time when it runs uh maybe it wasn't in compliant right maybe some new code was added that now it failed the quality compliance check and that's what I'm waiting for any questions uh any new questions come in Greg um nothing for the live session so okay so this is now completed um I am going to run another policy check now the policies at the release level usually aren't happening um in real time right that might happen once a day or you could set the uh the jobs to run every hour or so or you could just run them on demand like I just did uh now that we have the results of the test uh I if I go to the build here I can see that this actually has a failed uh execution right so that's something new that was just introduced um I run the policy and then the software quality scan here if I refresh this after the policy runs I will see that it's no longer incompliant and the last run shows that total test 13 only 12 of them passed right so that's a 92% passing rate that's not very good in the software development world we want to see much higher rate of passing that is something that I'll deal with at the release level okay but now let's look at the compliance aspect of this I'm going to go uh now I'm a a compliance officer I have responsibility at a higher level of insurance uh compliance management across many different uh Frameworks so we have ISO 27,000 we have Coit we have all kinds of uh uh different Frameworks here uh underneath these Frameworks are policies like you see here but also control objectives so I'm going to go to look at a control objective here and we can see okay one of the control objectives that rolls up to uh one of our Authority documents there is to make sure that we test all software changes before implementing in production now for some customers it's enough just to make sure that the test exists and and you're you're you're basically having a trust verify uh relationship with the application teams make sure the test exists and also make sure that the test will keep things out of production so if the test exists that's enough to meet the control objective okay for other customers they want to actually see the results of the test uh as compliant or non-compliant in this case there's 332 incarnations of this of this control for various releases of various products s okay that rolls up to a um an 88% overall compliance level now you could filter that and say only show me what's actually being deployed to production and that would be much higher right because we we understand that in the development process you will have failed tests that's that's what development is all about it's you want to fail fast and fix things and and so on so you can you can adjust this to to you know what really makes sense from a compliance is it enough to uh just hey the the testing exists in in the pipeline or do we actually need the results of the test that's up to you that's up to your compliance officers to decide we have the flexibility in the tool to to to to work in any of those scenarios okay so that that compliance check shows up there for this particular uh control okay and this is the control objective for this particular control we can see that the 4.0 version of this product is now showing up as non-compliant and that's the uh that's the indicator I want to understand uh you know most of the ones that have run are compliant and that's great okay so that's the the the um the the the roll up of that one particular policy to the controls the controls are part of this control objective and the control objective is is is part of a hierarchical model uh and that's the that's the hierarchy you have uh your your covid or your ISO 27,000 uh and then that requires all these control objectives to be met and this is how that's tracked in our software compliance management any questions about this yeah Joe so we had some come through um so can an item be removed from the package and not impact the overall release especially ones that failed or are non-compliant yeah I mean that's going to happen at the at the um at the application Level so let's say you build something and it fails uh you could decide you know not to deploy it or not and then it won't you know it wouldn't be part of the uh of the package that gets that the compliance check then checks right um we are tracking every single build okay so that's happening for other reasons and and in in tools like devops change velocity and and digital product release however you decide what actually rolls up to the compliance level and that's usually things that are actually going into production most builds don't go to production uh but if something does uh then you'd want it to be in compliant however let's say you know you want an exception in a few minutes I'll show you how that exception process works okay any other uh questions yeah one more this also might be a bit more broad but how does this work with devops not sure if you're going to get to that so devops change velocity is that the question how does it work with devops change change velocity they just said devops but yeah let's assume devops change velocity okay let's quickly show you in devops change velocity what happens um I think it's also important to call out that there are change approval policies that happen at the change at at the deployment to production level right that can be very different from the policies that you're implementing on the application development teams okay so if we look at and I'm going to bring up another instance here uh where I have a lot more comprehensive change approval policies because I think it's a good question and it's worth diving into you know where do you delineate the policies where do you say okay these policies are uh change policies and these policies are application development policies that really are just about the Readiness of a product to be released right because that's what digital product release is all about is this product ready to be released when we look at changes in the in the in the world of change management what we're looking at is the impact of those changes and I'm deep into a change record here let me find the details uh that we have so for example we have risk and impact analysis I'm also looking at operational stability so a lot of these things are about you know when I'm about to deploy a change that came out of the release process I want to understand what's the impact to operations right we know we can you know look at the cmdb we can see all the CIS that are affected right the affected CIS you see here and I can say are there any active incidents are there any recent outages is the environment stable to deploy software to this is going to be policy on know change approval policies and I'll show you those in a minute that happen at the change level that we don't care about at the release level release at at the release level we're just saying hey is this is the product ready to be released did it pass all its test are there any security issues with the with the version of the product itself whereas for change management we're going to take in operational information as well we do want to make sure developers follow best practices so a lot of that data might also roll up to the change approval process uh but also we might also want to look at security scans it's really up to the Auditors what they expect in the change process but many of these things you see here if you trust that it was done in the release process process then you don't need it in the change approval process and I'll show you what the change approval policy might look like okay so that's a delineation in policies if it's impacting uh the production environment and you want to understand the impact of it and you want to understand the analysis of it uh and you want policies in in place to make sure you don't impact production that's those are the policies you focus on here whereas the policies in the release process are just focusing on the quality and the um the security of of the software whether it gets released or not many things get built that you know and you might skip a version and actually deploy the the subsequent version but still it has to go through the uh the process okay so these are some of the uh approval policies you might see in the change approval process so I guess to go back to answer the question there are two separate there are two separate things you have change management and you have release management and the policies are applied in different ways but they do relate to each other so uh when we when we look at a release we can see all the changes that of that all the changes for that release that are being deployed does that answer the question does that all make sense okay any other questions uh Greg no that's it all right okay so I did want to talk about the um the exception process okay so let's go back to uh digital product release workspace I have a policy here that I know it's not compliant so maybe um you know maybe there is a uh a reason for it but maybe I still want to get it into production and with the proper approvals I can so we can see you know from the mappings of this policy to the various stages of various releases uh where this falls into place so what we can do is I can actually request an exception okay okay and requesting an exception means I can take this policy and say Hey you know this is this is uh low risk um uh allow me to deploy it because the software issue is not that big a deal and you can say okay let's I'll put this policy exception in place for a certain amount of time I could go in ahead and request that that's going to kick off a workflow for compliance managers okay so if we look at the workflow if I go back to the compliance workspace that particular control has an owner okay uh the owner of that control is going to be uh let's say like a a compliance team a compliance management team and so on and they're going to uh they're going to get an exception list and if we go to the list we can see all the policy exceptions here and all the requests for exceptions all right here's the one I requested for uh policy and there's a there's a workflow somebody has to approve this and when that uh when that gets approved we can see okay what's the impact of this uh we can um go through the process of reviewing it analyzing it once it's approved and once it's in place I will be able to get through the um the release phase and that will show up as a requ as a as a as a policy exception okay so everybody will understand that this was allowed to go through the release process but it will be very transparent everybody will see that there was an exception made to allow this it's very important because there will be exceptions and as long as there's a process in place and as long as it's documented and it's approved this also satisfies the uh the uh uh compliance requirements okay um okay so that's really all I have on the uh on this solution and would' love to hear some feedback if you can post some feedback in the chat about what you saw here today that'd be great and whether this would be useful for you in your uh environment that would also be great and if there's something that I didn't show and you have more questions we still have a little bit of time to cover those yeah Joe we have a couple more uh questions sure uh so can the request exemption process be implemented in the change management module as well well so that request process is handled right now the change management change approval policies don't use pace and they don't roll up to irm however that might change in the future what I just showed you is a is a capability of of policies in irm so if you have policies in irm then you can request exceptions so the the short answer to your question is no you can't really Implement that with the change approval policies but hopefully that's something we could address okay and then we have when changes are created from release management What fields uh if any are captured in the change ah okay so let's take a look at that so if we go back to our uh product release workspace and now go to a specific um release here so we were looking at the four .0 release and I went through and I showed you all the changes that were created for the release now there are couple of types of changes if I if I create a change manually from the release dashboard it will create a change and you know I could fill in all those fields manually but if you're automatically creating changes and and this is done through devops change velocity you can decide what fields in the change get filled in a couple of different ways you can use um templates that would fill in the fields or you can use you can actually push data in through the pipeline there are documented ways of doing that so if you have variables in your pipeline that represent data that you need in the change record you can that when you open the change record from the pipeline and again this is through devops change velocity you can populate fields that way uh but then there's also the um the there there's one more way to do this and that's when you dictate that you want to create a change in your application and I and I'll show you how we're doing that for this particular application uh you can also specify uh some in the in what step of the pipeline you want to create the change for example this is my uh deployment pipeline we're tracking the steps of that Pipeline and I'm saying let's create the chain at the production deployment I look in here uh I can also specify some data about the change record like the assignment group or if I'm using a change model or not and so on so that's three different ways you can you can um do it through the pipeline you can uh do it through you know manually open the change or do it through a template uh you can specify the template here and then that would fill in data right or you can uh you know fill in some fields from the step of the pipe L itself in the in the devops change velocity great so we have one more question and then Joe we also have a poll we want to run as as well awesome so for the question have you seen com uh companies use the release process for managing application changes and not development yes we're getting a lot of that right now because of thease management V2 being deprecated and a lot of customers use release management V2 for like application service releases and for tracking the resolution of incidents against those Services when you when you release fixes that fix those incidents for example so yes we we do have a lot of customers doing that uh and working on that today and the idea is that um even though a lot of the terminology in the digital product release today doesn't uh fit you know application service or service oriented releases uh it's still very uh valuable to to use it for that purpose yeah but that's being addressed so we will be able to like for example associate catalog request items and incidents and problems with the releases and tie back to uh Business Services more directly and you'll see the first iteration of that in November yeah great okay I'm going to run a a quick poll please feel free to keep posting questions as we do it um but let's launch this poll okay so we're really just interested in learning what you're doing for release today um and gauging your interest about uh DPR now now that you know know more about it so please take some time to fill this out like a minute or so e okay we're not getting a ton of responses that's that's fine we go ahead and end it now and share the results all right so overwhelmingly it's about the roll out of software packages to production and that's where uh the release management process begins and ends but uh there are quite a few customers doing end end including the life cycle uh the Planning and Building part as well yeah I think when you talk about the roll out of software packages production you're also including not just homegrown software and and application development efforts in house but also like commercial off-the-shelf cart software as part of that release process too I would imagine so that's why that number is so high [Music] great we do see some folks interested in um DPR but I know you're still the early stages for folks who do want to learn more uh if you're newer I'll share we have a lot of good um self-served content available on our community site so I'll share a link to an article which I've posted in the Q&A as well this is a good starting point to the community it it's a introduction to the product um and then at the bottom of that there are links to there's a link to an overview video and links to additional content so we have uh a webinar deep dive series that we ran called our launch and learn and then we also have links to our Taco uh training course so there's some good stuff there if you want to learn more please um start the Poke around and explore and then also feel free to activate the product in subr and start to play around with that Joe any any final final remarks no just thank you everybody for participating and um thank you for allowing me to uh to demonstrate the solution awesome and then once again so since you registered for this you're automatically um registered for our future modern change Academy sessions so we'll be posting um the topics uh a couple at least a month in advance for each one so we'll we'll try and have the calendar posted as far in advance as we can there'll be different topics focusing on um spanning multiple products a lot of um you know combination uh uh combination use cases like we saw today so a lot of good stuff will be coming uh down that pipeline so really thank you all for joining thanks everybody