sure hey folks uh i'd like to welcome you to the 14th uh session of uh creator workflows and platform academy um today we are going to be covering flow designer good practices so as always we've got our wonderful presenter uh lisa hollenstein uh we've got myself kieran mcmahon i'm a product manager here at servicenow and we have uh adam stout who's the director of outbound product management and without further ado i will hand it over to lisa to explain a little bit about our session today all right thank you so much um right so my name is lisa holdenstein i'm an apple product manager for credo workflows i've been working on the servicenow platform for almost six years and i just have my three year anniversary at servicenow um i'm so glad to have you all here um just before we dive into things um well you know this one but i'll mention it anyways a wonderful safe harbor statement um there may be some forward-looking statements please don't make any purchasing decisions based on them so today we're talking about flow designer good practices and i know i promised you some specific use cases but it turns out we actually have so much guidance to share with you we had to split up our content into two or maybe even three sessions so make sure to follow the academy overview post on the community to be notified when we schedule the new sessions specifically the ones for flow designer we'll have another session covering migration use cases and probably a third that will go into a deep dive around performance and debugging tips so very very valuable content there in this session today um we'll still have a jam-packed agenda so we're um this session is filled to the brim with info and guidance so um i want you to get comfortable and also hold on tight so please put your questions in the q a panel we'll answer them as we go if it fits the topic or at the end of the session so and before we get into things i want to ask you right off the bat the first poll so i want to know um and we'll look at the results in a bit i want to know how familiar are you already with flow designer and what have been your biggest objections so far so for you or your organization your company your customers what is keeping you from switching from workflow and orchestration over to flow designer and integration hub so let's see those answers rolling in while i start giving you a brief overview of the flow designer history so what happened flow designer has been around for quite a while now so it's been over four years now i couldn't really believe it but until i looked into things but it i believe we released it um actually in kingston so uh way back then it was more of an alternative really to business rules and maybe some alternative to business rules and also email actions reimagined in london then we went beyond orchestration with complex and dynamic integrations and catalog fulfillment we also added reusable components then madrid brought foreground or background execution to help flow designer become a real workflow alternative and for it to be ipos ready since new york we've been expanding on integration hub to deliver enterprise-grade integrations but we also added a run from api options so we have a quite extensive flow api by now and a lot more flow configuration options then in orlando we brought action steps to easily parse and use complex data so for example the xml parser or json parser which are super handy and we also added dynamic flows and dynamic action inputs and finally transform functions then in paris we went further we added run with roles so before flows would only run in a system administrator context but now we can actually determine which roles it should be running in which is a super awesome security feature because a lot of flows run in the context of the user that is triggering the flow so for example somebody posting a work node or a comment on a task but that person may not necessarily have permissions to write to a different record so with run with roles you can grant that role specifically only for that one execution or while it runs we added more security features like content access filtering more details on that later we added decision table actions which is super handy especially with the new decision table builder and some quality of life improvements like duplicate actions and soft flows flow data definitions allow you to collect data at runtime this is specifically used for process automation designer activities and make those interactive then the second to last um was quebec and quebec brought a lot of improvements on the citizen developer side we had a ui redesigned to make the flow designer a lot more intuitive uh we brought flow variables a feature that was asked for for a very long time because people were missing the scratch pad flow designer also integrates natively with app engine studio and in that context allows for flow templates and there's also a new ui to set feature access definitions late last year we had a rom release which brought a bunch of functions around error handling so we brought action and flow error handling we made some improvements to flow performance and you are now able to set your logging levels to your knee and also a bunch more new transform functions because those are all always awesome we have 10 out of 12 that have been using flow designer at least for some use cases which is a good number but i really hope i can encourage you to use it more after this session or with this session and then what have been your biggest objections um we see features usability performance so security is not as much an objection but i can see that there's something in chat too so brian posted it was error handling yeah so error handling is something that should be solved with rome and moreover also with san diego so i hope that objection will be out of the way soon so san diego what happened in san diego we brought more options for our handling with a try catch error logic so that is a really great improvement on this side but let's start from the left so when it comes to usability and adoption the san diego release is probably our biggest update yet and we hope that flow diagramming is the ui enhancement that can sway most people who have been hesitant to make the switch so flow diagramming will allow you to see the paths of flow and take and the connections between the different elements so specifically for your nested if-then-else constructs for doing stuff in parallel finding out when a branch will end or not it's always good to see that um and it will be easier to see that with flow diagramming it's not full fledged yet it's the first release of flow diagramming so um i just want to point out here right here is we're of course um going to be extending the scope of what is supported by flow diagramming um so don't worry about that and then the second part is saving flows as templates right now you can start and enable this feature on your instance um to save a flow as template and i will have some more details on that later so those are really awesome you have some more smaller enhancements like managing feature access to the flow error handler more transform functions you can now use new date and time simple math string end utilities transform functions and then one thing that has also been changed that maybe people have not seen yet when you look at the the trigger record uh data fields there's a run start date time data pill and it now stores the flow start date in local time and we have renamed the run start time data fill to run start time utc so that you will always have the universal time data pill available to you as well so that is a minor change but important to know i think i think it's a great addition yes so i've seen your objections to flow designers so far and i want to give you some arguments for migrating and personally my first is just embrace it like that's my greatest recommendation that i can make is flow designer is here to stay so you might as well embrace the journey towards becoming an advocate for flow designer i know i am i love to use flow designer and use it whenever i can and the more you use it you'll be become more more comfortable with its features and with that you'll it'll also be more powerful than you may imagine right now so that out of the way we'll start with an overview of our main arguments for flow designer and have some more detail on each of those points in the following slide so first of all and that's really important workflow is not being removed or retired anytime soon this is like say farmer applies but as you can see in your platform in your instance i mean execution plans are still there right but most importantly a workflow has entered a maintenance state and that means we're no longer actively developing new features for workflow or orchestration and all new innovation is being poured into flow designer that's really the the main reason for you to get started switching and i'll walk you through some more reasons flow designer has better performance across the board it is faster it is more reliable it incurs much less tech depth than uh scripting and therefore really lightens your load when upgrading your instance so i'm using flow designer and reusable um flow actions will help you keep your upgrades safer because you don't you're not reliant on something being changed on you that that will make your script not work anymore you don't have to hunt down the person who wrote the script three years ago who may have left the company so that is uh also part of an argument for reusability and usability so creating soft flows and flow actions for you to reuse them in other contexts and also create con contained units of logic that are easier to understand and maintains and more easily discoverable just imagine if you're a new onboarding developer you don't know which kind of functions may be hidden in that random script include util xyz that has been created five years ago maybe that has the functionality you need or it doesn't but if you go into flow designer and open the available actions you can browse them you can search them you can discover what's already there and if your company has a good um strategy in naming those spokes and naming the actions you will find you will probably find what you need and reuse it so looking at the flow designer layout especially with flow diagramming that will make it easier to understand what a given flow does and it is much easier and faster than it would be with scripts and that goes for all kinds of developers so that's not just for citizen developers i mean experienced developers will find it easier to understand what the flow does as well with just the glands speaking about low code developers flow designer is a lot more accessible to low code developers and there are guardrails that you can establish to make sure they only use the features that they're supposed to use so security features and access limitations allow you to invite citizen developers into creating business logic and establishing those guard rates um helps so they don't accidentally delete data or update some records that they shouldn't and this also helps building trust between the pro and the low coders and lastly and most importantly flow designer and integration hub have reached and exceeded the functionality if not before then at the latest around the quebec release so i we really think that by now there shouldn't be anything that you can't do with flow designer except for one or two very minor things and those have been decided on purpose so one good example for that is rollback the main reason why our engineers decided to not have a rollback function in flow designer is that it almost always led to problems for our customers so imagine you have some business rule or a workflow that changes maybe five records but changing one of those five records changed three other records how far would you go in that rollback how many rules do you need to dial back when you unroll a change so um because those things usually led to more problems than was helpful they decided to not build this functionality into flow designer and as always if there are things that you are still missing in flow designer there's a lot of functions that you can create yourself with custom actions or if there are logic portions that you are missing there's always the idea portal on the community so feel free to post your ideas there look around what has been posted already upvote because the more votes those things get um the more likely it is they get implemented and are visible to our developers and inbound and product owners then performance so what is it about flow designer and performance one of the reasons it's better and more performant is that it is running multi-threaded and as opposed to for example single threaded business rules that's one of the reasons why it's faster um the second reason is in foreground and background execution um workflow would only run single threaded in the foreground so whenever a workflow would be created and you wanted it to be put in the background so that the customer or the user would be able to use their interface and continue their work they would add a timer as a first step to push the workflow into the background so that workaround isn't necessary for flow designer because you can define that on on the trigger level you can decide on the trigger level or when calling it from the api decide on whether it should run in the four or in the background the third point that i was told by our engineers is that floaty's interactions actually stay on the java layer so they don't call javascript and therefore the execution will also be faster and then lastly um something that i mentioned before already it reduces upgrade costs because you will replace custom complex custom script or with upgrade save platform logic and this way you will also lose less knowledge when your developers leave the team or the company and you reduce your uh tech debt so usability reusability flows i mentioned that already are easier to read than non-scripts so you don't need to have any javascript knowledge to use existing subflows flow logic or flow actions flow diagramming will make this even easier so being able to better understand where the flow will move after exiting an if or a tri-logic block and you can instantly understand conditions branches and decisions because it will actually label the different paths like which decision has been taken here so if you have an if it'll label the different paths true or false so you know which way is it going to go so the single ide for configuration runtime information makes it easier to not just create but also operate in troubleshoot business logic from a single interface so when you're creating your flows you have the test button right there you can check out the execution logs and you can also check out the connection dashboard to decide on which connections you need to configure so when you're already using flow designer it makes it much easier to get started with process automation designer if that is interesting to you because process automation designer allows you to create more complex processes which can then include multiple phases cross-departmental information transfer and most of all playbook experience will bring processes to the forefront of agent work so guiding your users through a process making it transparent where in the process they are where they stand which steps to take next to proceed in the process is super valuable so i highly encourage you if you have dabbled with flow designer already check out process automation designer as well and then shifting gears into accelerating and enabling citizen developers is the new option to save work to save flows as template for repeated use in different contexts so imagine creating a template for service catalog fulfillment for example that can be applied and adjusted again and again to meet any catalog requirement the good thing about promoting a process automation here is that your smes your subject matter experts your experienced developers can create reusable flow actions subflows and also flow templates that the process owners and local devs citizen developers can then use and reuse more usability it was so much i had to make this choose so i've mentioned flow variables before um they're not specifically an advantage over workflow but because that already had scratch pad but it's still an advantage over earlier flow designer versions and maybe also scripting because you can see the runtime variables in their own section of the data panel so if you look at the data panel on the right of your flow designer you can see all of your flow variables in the top and you know they exist in this context and then you can more easily find where they are used and how they're used as opposed to hunting them down on the workflow editor pane or in a long script flows and flow actions um can i think i believe since the rome or quebec release can be natively called from virtual agent designers so this allows for easy automation of customer or employee requests directly from conversational interface imagine having a conversation a virtual agent topic that automatically triggers an integration or updating some records sending a notification without having to do that manually invert and virtual agent but you can use and reuse existing logic and flows for that third part on the first row is reusing data streams so once you have data stream actions created or third-party integrations getting data from other systems like your maybe your mhr system of record or your erp system of record you can reuse those data stream actions as data sources for your imports for your data imports and you don't have to implement the same integration multiple times and what's also very useful is the integration hub import product for robust low code and modern data mapping so no more need to manually assign values and map them you can use a modern interface for that now too it supports data mapping for data streams in rome releases in the rom release and imports from xls with the san diego release so that's a new feature you can now also import from xls which is also integrated into app engine studio on the error handling side i've mentioned before try catch functionality is a very new one so we can now allow you to try a certain logic code block or logic block a sequence of actions and then decide what happens if one of those steps fail so if you have tried this a certain number of time maybe three four five times or whatever what should happen how should the flow proceed then and then also handling flow and action step failures with regular error handling that was introduced last release um and you can decide how to proceed it may be useful um sometimes to decide that you actually want to suppress an error so if you have an action you just want it to proceed or you don't want to surface um an error from a subflow up to a flow and that can be done you can also you make use of the retry and notification capabilities here i've already mentioned the connection dashboard uh using credential templates helps you set up connections and credentials easily and one of the baseline function functionalities that has been around for um i don't know long for years is the connection aliases and that is fully supported by a flow designer an immigration hub so you can make sure that you can have different credentials in each of your instances so you may have a different set of a different path a different set of credentials for your test environment or your dev environment than you would have for your product environment and then of course um just to to give a shout out to integration hub when thinking about integrations with other servicenow instances or third-party systems always look at the ever-growing number of baseline spokes we have over 175 by now with thousands of provided spoke actions so check those out before you start your own implementation and this will save you literally hundreds of hours of implementation times it will make your upgrades safer and you also don't have to worry about ap changes to remote api configurations so if the remote systems have a new version or whatever that's what we take care of if you use our baseline spokes all right i was gonna say that's one of the things too is that i think a lot of people had exposure early on and and maybe didn't really see the full feature set but you know as the product matures there's so much that's been added and so many fundamental changes because you know all of servicenow is really behind this functionality and the way that we're working and that's why you know i'm glad we have sessions like this to really get it out into the community and maybe give have people give it a second chance absolutely i i know i know i was frustrated with flow designer the first two three releases because things just wouldn't work the way i expected them i was still a customer when it was first released and i wanted to use it but i just couldn't in the beginning but it's it has changed so much but really there have been so many great improvements in the past four years it's it's not even the same product anymore exactly i mean eric mentioned earlier in the chat he said you know flow designers philosophical change compared to workflow and it's the process isn't one to one but but once you kind of embrace it there's just so much more that we have to offer with it yes yes absolutely and speaking of things to offer flow diagramming look at it it's so pretty so uh one note one note about flow diagramming um we found that at least in the san diego ea release so the patch zero release um it doesn't activate automatically as it should so you may after upgrading you may have to go into the plug-in list search for flow diagramming and hit the update button but once you do that it should be there and it should be available and it looks like this you will have a toggle button in the top of your flow designer frame and you can toggle back and forth between the two views and an important note on at this point linear flow the linear flow view is not going away so that will be fully supported and it will stay so for some use cases it may be easier to work your way from the top to the bottom and in some cases it will be easier to visualize the different paths you have so you can take your pick and work back and forth one note uh though as of san diego not all of the functions are supported so we're working on expanding that over the next couple of releases so for example using flow stages will disable the flow diagramming function at the moment and i think a couple of others aren't supported yet like doing something in parallel but we're working on expanding that and more more and more will be available with of course the end goal is that you can fully switch back and forth between both views whenever you need it so just be careful don't be don't be alarmed if you cannot use it it may be that your flow has something that is not supported yet templates um i just added one small screenshot here so for flow templates to work you also have to install a plugin which is called flow template builder good examples for creating full templates would be as i mentioned before service catalog fulfillment maybe service level agreement flows or notifications so that users don't have to set up the whole integration part or adding the web hook or something like that so you can create um templates for sub close you can also see some of those in app engine studio already at the moment any customer can create flow templates as of san diego they're only available for consumption in app engine studio we are working to resolve this um also over the next couple of releases but i can't commit to a specific date right now but we're working on that so um we want to make this usable for as many customers as possible looking at decision builder we had a session on decision builder end of last year in december so be sure to check that out and also the creator toolbox with julia perlis on decision builder to find out how awesome it is decision builder empowers your process owners and your subject matter experts to remove decisions from the flows so actually removing the the decision from the business logic helps to have them own the decisions so maybe you want to have a specific assignment or send an email to a specific person or the group that will decide on an approval changes on the regular so whenever there's a decision that would change frequently and you don't want to run it through the whole change process all the time decision builders are your friend and also one question i saw the other day was how to do a switch that you were able to do in a workflow in flow designer and decision tables is your answer so either you create a complex if then if then else if then if then if then construct or you use a decision builder use branches if the decision output will result in different steps if it's the same step or if it's for example in every time you would create a task or in every decision you would send an email but just the recipient changes or the assignment changes or the short description changes then you can skip the branches and just the next step that is being done can make use of the output of the decision and use that as a variable all right what else do we have we can use and transform runtime data in mind so there are different components to this things that work really good together are on the one hand flow variables and on the other hand transform functions so you can create set and use runtime variables as i mentioned earlier they're very prominent in the data pane and then you can set them at runtime and reuse them and the awesomes awesome thing here is you can when you set the flow variable you can apply transform in transforms inline so you can i don't know split a string into an array or you can convert dates to string and all kinds of math operations that we offer here and if all that does not help your last resort would be in-mind scripting but we encourage you to try all the options other options first because if you use scripting you will have to hunt that down once something changes so be sure to use the the low code versions first and i've been many of us developers who have had to bang our head against the wall trying to convert one data type to another definitely appreciate any of these transforms that kind of natively do it for us and do it the same way every time yeah there's there's fun in here as well like sanitizing shell arguments or sqls to make sure that some input doesn't frag your whole back-end system so always always good to apply some some sanitation right here keep your sanity all right we talked about access control and guardrails before delegated development and the collaboration feature as it is called in avenue studio but it's also of course available in your dev studio is an important part of this you can decide for any of your scoped apps who would be the editors the owners for those apps but you can decide on a very granular level uh which access you ran to those delegated developers so it's not just that you have those pre-defined roles like editor and owner but you can you can create your own labels and you can also decide to give people access to decision tables or to flow designer or to process automation designer and make sure that those people only have the permissions that they need when they create this logic we've talked to i've mentioned access control these are just some of the features that you can restrict to specific roles the list is literally like two displays long you can scroll quite a bit to find out all of the features in flow designer that you can decide on on filtering so you can say for example that a specific role doesn't have access to integrations or they cannot set flow properties or they cannot use flow variables or they can not publish a flow or whatever so if any of the functions that are in flow designer you can restrict those if necessary and same goes for access control in the form of content filtering so this is the third level that we offer what happens here is you cannot only filter functions like activating a flow but you can also filter specific logic or specific actions in that you can for example say this group of people for example hr citizen developers when they create flows they can only have access to hr process subflows or actions you can say they may only use those spokes that are calling messaging apps like sending a message to teams but they may not use the sap spoke for example or the 80s folks so with content filtering you can even drill this down even further and make sure that people only have access to those functions and the spokes and the actions and the logic in flow designer that they need so just to not overwhelm them exactly i think that's one of the things that's really nice is is being able to actually tailor the development experience to kind of fit the persona that you need and uh you know it is overwhelming when there's so many options on the table so if we can really make it friendlier it's a lot easier to get people in there and start making functional benefits to their business units yeah i'll get to some migration guidelines so what should you do what should you consider when you're working your way from workflow editor to flow designer and from orchestration to integration hub so there's really fundamentally two approaches to migrating to a new tech stack and the first being the traditional way for eating a huge migration project and this would of course include several phases like determining the code base that needs to be migrated finding out tasks assigning resources and of course tracking the migration project progress the other approach is more agile so the second approach would be migrate as you go and i personally would encourage you to give this a shot whenever possible adopt new baseline flows and flow actions that we give you when when you upgrade your instance to new releases our product teams are working on replacing their previous implementations with new and improved flows all the time some of those examples are the itsm change flows they've now adopted decision tables for example for their decisions on whether something should go the path for emergency changes or not or if it's a an unplanned change and also csm has done a lot of work in the space of flow designer actions and they're also heavily using playbooks and and process automation design when you migrate try to set up development rules for your whole team say new requirements need to be done in flow designer unless it's absolutely not possible but i i think 99 of your work will probably be possible in flow designer involve other technology but then only for those parts that cannot be done in flow designer and connect those parts into your flow any change requests for existing logic should be taken as a chance to evaluate that part of your implementation so uh converge those things to sub close or flow actions to that end make use of the call workflow flow on logic so you can connect workflows and flow designer and go back and forth so you can incrementally replace your complex workflows and make the make those things available all the flows via flow api from the workflows and then connect everything that has been migrated already similarly you can reuse existing script includes in custom actions to make them available for use in flow designer until you find time to migrate them into dedicated spokes and then lastly we encourage you to get together in groups if your organization size allows of course find time to group or huddle to talk through tougher nuts and get other developers inputs on how to solve them when working with citizen developers some of our customers have started like something like development office hours where new developers could come and chat through any hurdles they face when creating their apps and business logic with experienced developers if your org is more small you can still engage in our community on the servicenow developer slack and um in the community and also maybe join dev meetups most of them are online at the moment so it's a lot easier to join those those meetups so so much for the general recommendation um really it's probably at the end of the day it's going to be a combination of both it's going to be larger projects for some things and smaller projects and incremental migration for other things what are some migration use cases so from workflow you will move stuff like service catalog fulfillment slas sla tracking or olas and basically any task life cycle processes if you have more complex processes consider using process automation designer as mentioned before so you probably have one or two giant workflows somewhere that go i don't know how many rounds and back and forth and so many phases and stages consider using a process automation designer for those and then you can use flows to replace all kinds of scripting of course so in order to reduce tech and improve upgradability use scheduled flows to replace scheduled jobs use flows to replace after our async business rules there's a tiny caveat here because flows run in the after context you cannot use them for b4 business rule however for very small flows where you only need maybe one or two steps you could theoretically trigger the small flows with the quick api from a before business rule so i'm not saying that's the most common case and you should do that all the time but in in some edge cases that may be really useful more about the the quick api will be mentioned in the next flow designer academy session um i'll add the caveat really i i want to emphasize this do not use this for large and complex flows do not run large flows brahma before business rule because it will just block your user from continuing their work this should really cover small use cases like getting some small amount of data from a data stream or maybe doing some quick calculations and then you can create spokes so any grouping of flow actions is called a spoke whether that's integrations or just general functions that you want to use to house the functions that you would use uh put in your utils script includes so when you're migrating your script includes create one scap scope give it a fitting image and a description so you can you can find it find it well in your list of actions in flow designer and then for each of the functions in your script include create a full action and just make it reusable make it discoverable so that would be a and if you want the low barrier of entry of course you can just read the spoke and then just call the existing script include from the flow action steps that's totally a possibility you don't necessarily have to replace it completely and then speaking of integrations moving our integrations from orchestration and scripted rest api into integration hub and flow designer may sound daunting but make sure to check out the existing scopes because there are so many there's also the option to replace scripted rest api with the relatively new inbound rest trigger um i think there's a crater toolbox session that covers how this works exactly but it's super handy to to have and to understand how to make data available to third-party systems and then as mentioned before you can use data stream actions as data sources for import the last part i want to mention here is outbound email um so we recommend to use the send notification action as much as possible because this helps keep your outgoing notifications stay consistent make use of notification templates and keep all notification configuration in one place if you don't have a notification you can use this an email action but be aware that acl restrictions apply to this so if you configured your flow to run as the user who initiates that it may be that user doesn't have access to use the mail email function so to test this you can impersonate a typical email sender and then manually trigger the flow to find out if and lastly any migration is a chance for change so use this chance to try and have a good look at your processes try to simplify processes does your process really need this many notification does it really need this many steps or can you make it maybe shorter or have less loops or whatever have less approvals and if you reduce the complexity of your workflows this will also accelerate the resolution of the tasks and the process and then on the more complex side i will say it again consider process automation designer it's it's an awesome tool if you're considering using it later build supplements for logical parts of your process those can then easily be reused for process automation designer activities break up large and complex workflows into smaller units we will recommend that anyway um for performance reasons so don't have flows that exceed 25 or more actions if you can use subflows instead to break out that into those units and then group activities by phases and blames wow that was a lot and i have another poll around this and around what we just saw so i want to know which migration strategy have you considered using or are you considering using going forward now that you heard about more different options and more different strategies and then also looking at our upcoming sessions which kinds of migration use cases are you most interested in so which should we focus on have concrete examples that we can show off in a demo i would love to see your input on that i think when you mentioned you know replacing script includes with um some of these custom flow actions i think that's a great thing that uh you know i previously hadn't thought about but um it definitely i think is a very very powerful thing i a lot of developers specifically like myself that was a huge thing you know creating these massive massive script includes but having them in a kind of reusable visual format where you can go and actually start making tweaks without having to pull apart you know this this massive self-referential document it's that's that's a big change and i think uh if we start driving that and and people in their organizations can start driving that you have a lot of reusable code that's going to be um really beneficial so that's a that's a great option that you pointed out and a lot less duplicates really you don't you don't have to write the same solution five times like getting getting a message or getting a system property can be just one flow action you don't have to redo a script all of the time or calculating some specific i don't know some specific measurements or stringing together fields in a specific way to meet requirements of a remote system you can do that once and have it available for all of your uh all of your developers exactly exactly all right awesome i see a lot of answers coming in i'm hoping for one more maybe we can see that yes most most people are considering incremental migration which is a really good idea and then combine it with smaller projects things that i could see can be smaller projects are things like service catalog fulfillment that can be a smaller project in a larger scale and while doing incremental upgrades too so every time you touch something consider moving it to the new technology but especially for um any business area that has optimization potential or harmonization potential and service catalog fulfillment is is one of those areas where um it is beneficial to have somewhat standardized fulfillment maybe having similar phases for all catalog items or at least all categor catalog items for a certain category right um those could be projects to make sure they have the same look and feel to the end user yeah so i want to share the results people want to people want to see service catalog fulfillment schedule flows replacing script includes with custom spokes yeah you said it it's i think that is a really interesting part all right we're almost at the end of our time um i think this was my last slide we have some q a i can see that andrew was already answering a question in chat which seems to be a specific case and then with that before we head out um i have one last poll we don't want to forget this one we have our academy feedback poll i'd love for you for you to give us feedback on the session i hope you liked this session i hope you found it informative and it makes you want to join us again of course and while you're clicking your way through these few questions i i want to give you a quick outlook over the next couple of academy sessions we will skip the next occurrence so there's no academy on march 3rd i'm really sorry but it just doesn't work out um for us this time schedule wise but we will pick things up again in a month so in four weeks which would be march 17th you've probably noticed today that we can finally talk about san diego features uh we're an early access phase of this release and it's super exciting um like every time i think it's our best release yet but every time i think it is it is actually true because we're surpassing ourselves every time so san diego will be generally generally available in march but most of the release notes are all and updates are already available on the docs page they're still being updated there's still some changes being made um so keep an eye out for um for for release notes that are important to you and our awesome developer advocate team has also started uh creating awesome blog and live stream content about the san diego release if you want to catch up on all new features for creator workflows and the now platform there was the techno episode 93 it's available on youtube but you can also join us over the next two or three academies because we're going to be covering what's new in san diego for greater workflows and especially now platform and we'll have a special focus on the next experience so we're very much looking forward to having amanda johnson and ashley snyder joining us again as as guest speakers since our last next experience session um had such great success uh and we're really excited to have them back on our show yeah i'm gonna say i think we're not the only ones who are excited about san diego there's so much information and excitement in the community of people blogging about it mentioning it and you know uh really glad to have the tool in everybody's hands and i'm really glad that there is such a thirst for it so realizes that you know we're not the only ones who are very excited about this release and all the potential there is to it yes totally so the next academy sessions after um those that are focusing on um on san diego and and the next experience will then be the deep dives into flow designer that i promised earlier so we'll talk about specific migration use cases we'll take your votes and and weigh things accordingly and we'll also provide you with tips and tricks to improve low performance and how to debug when something goes wrong which i think will be super interesting as well all right thank you so much for your for your votes thank you for joining us for this uh flow designer session we hope you really enjoyed it just as we did and we i really hope you start using flow designer and advocate for it because it's it's amazing as always we share this presentation on the community i'll post the com the video once we have it on youtube uh we'll edit it and upload probably early next week um and you'll find a lot of more resources on how to get started training and blogs and all all good stuff in the appendix of this presentation all right thank you so much thank you thank you andrew mark and adam thank you everybody for joining us and see you soon cheers