[Music] hello hello and welcome to the workflow Academy in this comprehensive platform Academy video series we'll dive into the transformative world of workflow automation empowering you to build Monitor and optimize efficient workflows with ease join us as we explore the core tools to build flows and subflows playbooks and decision tables on the now platform hi my name is Lisa horenstein and I'm an outbound product manager for the now platform my area of expertise is work for Automation and I create enablement content videos articles and blogs on the now Community I have been with service now for over 5 years and have been part of the yet service now ecosystem since 2016 before joining service now I was a platform owner admin and developer at a customer I am joined today by Julia Peis please give a quick introduction to yourself thanks so much for having me in this session Lisa um hi folks my name is Julia Peis I am a principal product manager here at service now um I've been with the workflow automation team since 2020 and I oversee all things decision tables and decision Management on the platform and happy to be here to talk to you about decision tables today we have two platform Academy sessions on decision builder in our catalog of recordings one we did back in 2021 and an update last year but we thought it was time time to do a fresh cohesive overview of everything decision tables as of the Washington DC release just a quick reminder I may mention coming releases or product features that are still in development all timelines and features may be subject to change so please don't make any purchasing decisions based on anything we say today so today we'll not just do an update but a comprehensive overview of what decision tables are who can use them and where to use them and of course tips and tricks as well as the Mo decision tables are part of our workflow automation tool set and when we talk about workflow automation we always want to strive towards our common goal which is to empower anyone to automate workflows even without code in the past couple of years we've introduced several purpose-built workflow solutions to build workflows on the app platform it started with flow designer and we added process automation designer and decision builder in the past couple of years with the Washington DC release we're introducing worklow Studio to bring all of these core platform capabilities into one Builder applications distributed through store apps receive updates every 3 months allowing us to innovate faster and you to benefit from the newest features more often these store releases come out in February and August with a family release Early Access versions and additionally in May and November make sure to check the application manager for the latest version of workflow Studio since the store release in May 2024 all Builder updates are included in the workfl studio app so you no longer need to update flows decision tables and playbooks individually so let's focus in on decision tables what are they good for and why should you use them decision tables enable developers to decouple decision logic from their code to create and maintain decision rules in applications with decisions it's seamless to update your business rules anytime as you can modify decision rules without changing the code with decision tables you simplify your flows and scripts by building reusable logic and you reduce your change burden decisions can be created and maintained in workflow studio with an intuitive low code UI different roles Grant fine grained access to either just the results full decision rows or the whole decision table decision tables are made up of different parts we have inputs and results conditions and condition rows we'll learn more about building decision tables in our demo later as with many other development features on the now platform we can decide who can use decision tables to which degree with delegated development permissions there are several levels to determine access to building decision tables first the application layers if you don't want to give your workflow developers full admin access using delegated development or app collaboration is the process of choice second the designer and feature access layer we have different roles that Grant users different access to reading creating and updating decision tables the decision table reader can view decision tables and Export to excel the decision table result editor can edit the content of result columns the decision table rule author can add delete and rearrange rows edit conditions and result values and lastly the decision table admin can do all of the above plus configuring inputs properties as well as condition and res columns third for business process owners that don't want to work in service now at all a service now developer can build the decision table outline with inputs conditions and result columns for them then the process owner would fill out the table and return the completed Excel file to be uploaded for them to learn more about securing the workf flomation toolkit check out my article series and platform Academy video that I published on this topic last fall now that we've established what decision tables are and who can use them we will go through where we can call decision tables on the now platform the premier place to use decision tables are of course flows and subflows with the dedicated make a decision flow logic let's look at a first example to demonstrate the power of simplifying your flows and code with decision tables in this flow we want to have different groups to approve and fulfill a request based on the category of the catalog item without decision tables we'll see if the N logic branching in the flow that can get unwieldy really fast and it's hard to keep track of all the options once they exceed to our three paths additionally each fulfillment beyond the approval in this case is basically the same except for the assignment group but we'll have to keep it updated in multiple places if the slightest aspect of the F fulfillment task notifications or updating the record changes in our example we will now use this decision table instead of the multiple if then else branching to determine the assignment and approval groups for different catalog items you can see the conditions inputs and result options and also the default result if we use this decision table in our flow you can see how much less complex it is with the to make a decision logic we can remove the complex if then else branching and instead use the outcome of the decision table for all subsequent steps the approvals and assignment the default resol works as a catch all option so that the flow is more flexible when you add new categories and still have an a way to pach those options without having to touch the flow after covering flows let's look at playbooks as of the Washington release we have two ways to use decision tables and playbooks in both cases we have to wrap them in a subflow any subflow inputs and outputs will be available when creating a Playbook so we can hand in any data we need to make the decision if you then map the decision results to the subflow outputs when you use your decision subflow in a Playbook the outputs will also be available for conditional branching allow allowing for very flexible design patterns in a future release we plan to make decisions natively available in playbooks as well to remove the extra steps of wrapping them in the subflow to learn more about how to build custom Playbook activities check out this workflow Academy that I published earlier this year Beyond flows and playbooks you can also use decision tables anywhere on the platform where you have a script field to give you a leg up we've added the option to automatically create a code snippet from the decision table the method that is included in the code snippet generated from your decision table is make a decision this allows you to get the first result row that evaluates the true or an array of all matching results from a from the given decision table Additionally the uh decision table API also allows you to manage decisions create update or delete any component of a decision table so for example answer elements conditions or inputs you can then use the snippet in all kinds of different places for example business rules script includes UI policies data lookup rules uib component visibility rules ACL logic and more one example that I'd like to highlight for the use of the decision table code snippet is in a custom flow action calling a decision table in an action script step allows us to make decisions for an otherwise linear execution this is particularly useful to determine connection and credential aliases for Integrations or to replace the need for storing data in system properties like remote URLs for test and productive integration endpoints however we recommend to be very mindful of using this in flow actions and not to build out complex Branch logic within an action any single flow action should only ever serve one purpose and not cover complex scenarios once you need any form of further branching or looping we recommend to encapsulate the simple operation in a flow action then create a subflow for the more complex logic in decision making so now let's look at some tips and tricks for decision tables added in the Vancouver release for each decision table you can decide to activate draft authoring this enables an extra safety layer so that your changes don't take effect from outside of testing until you publish them speaking of testing the testing function allows you to test for either the draft or published version of a decision table table inputs will be surfaced in the test model and you can choose to return either the first decision that matches or all rows that evaluate to True a common question we see on the community when using decision tables and flows is whether and when to use the branching for most use cases we think you won't need branches in flows when working with decisions which greatly reduces the effort for maintaining the logic it is also the most flexible option as it inherently catches new data variations with the default result you should only consider branching if the steps after the decision are significantly different from each other but even then I'd personally suggest to learn to use Dynamic flows to unlock an amazingly powerful design pattern not only can you use decision tables to determine groups users choices strings and other results but you can also decide which subflow to run with the dynamic flow flow logic decision table should follow your standard application life cycle to be created and modified in a subpro instance and then promoted through your preferred pipeline be that update sets or Source control at app repo as outlined in the who can use decision tables chapter there are different options for granting limited access to updating decision tables with delegated development and dedicated roles for business process owners that usually don't work in your subpro instance the edit in Excel feature allows you to give them an extra guard rail path to own their decisions before we head over to an instance to give you a walk through of all the features available to build decision tables let's look at some possible use cases in a nutshell decision tables can be used for any conditional branching on the platform replacing if then else or Cas switch statements whenever you have more than two forks in your logic and reasonably expect that the specific condition value may change in the future you want to consider decoupling that from your flow or script so let's look at a live demo to walk through decision tables built in workflow studio all right well thank you so much Lisa for such an amazing and thorough overview of the product how it works and how it's used and now I will take over and show you how it works in action we're going to walk through a scenario today where you'll see how powerful it is and how flexible it is to use a decision table instead of hardcoding your business logic into your flows and your code so the scenario we're going to talk about is an art school this is a school where there's some teen programming there's some adult programming and there's a whole bunch of different art classes and students need to submit applications for classes and so there's a couple things we do obviously there's an application review process but even before that we need to based on information about the student and information about the class determine if that student is eligible for the class so we have a whole bunch of different conditions to do that um I'm a developer at this art school and I worked with a departmental team that shared with me their logic for eligibility for their different classes so they shared this Excel spreadsheet it has some information about the class the age the student is going to be for the class and whether it has a prerequisite I've worked in flow designer quite a bit and I know that trying to translate this into a whole bunch of if statements or if statements is going to be very gnarly it'll have a whole bunch of branching I will probably have at least 30 steps of my flow that are just hard-coded logic and then when inevitably they realize they want to change some of the eligibility criteria it's going to create a big headache for me so I know this is a great opportunity instead of using the if statements available in flow designer to instead use a decision table to manage this logic so I can see it more clearly I can build it more clearly and I can maintain it much more easily to get started we'll go back to our homepage for workflow Studio here as you can see within workflow Studio you can see all of our different workflow assets including decision tables we can create a new decision table from here and safe harbor applied coming in a future release we're actually adding an enhanced experience to create decision tables directly from your flows so stay tuned in the future for that new feature that will make it a lot smoother to even integrate your decision tables into new flows we're going to create a decision table here for eligibility and the assignment group if someone's eligible we'll assign them to a different departmental group and that group will oversee the full application process we can choose to add a description if we want to provide more context to anyone who might work on this decision table in the future and you can choose which application to store this decision table in if we wanted to give delegated development access to someone who is managing these decision rules we might put it in a specific scope so that when you give them delegated Dev access they have access only to a narrow set of decision tables for their use cases in this case I'm going to keep it in this decision examples application and we're going to make it accessible from all application Scopes this means that no matter what scope you're building a different asset in like a flow you'll be able to access and execute this decision table one thing I'll call out here that Lisa mentioned when she was talking about the different features of decision tables is that we have draft authoring enabled if you want to learn more when you're building you can see some information in this tool tip message and we also have more information in our documentation but what this lets us do is start working on the decision table and making edits to it testing it before publishing and making it available to use in a flow or call Via a script what you see here is the blank canvas we have to work from very appropriate given our art class example you can see below with our decision table that we are being guided first to create inputs before actually building the table the inputs of the decision table is where you define the different types of data that you're going to evaluate to make decisions so this is the data that you want the flow to pass pass to the decision table so that you can run a bunch of rules on it and return your outputs based on the different combinations of conditions in those rules for everyone who's uh familiar with building subflows and flow actions um similar patterns apply here so you might want to uh think about what kind of inputs you want to hand in and what kind of outputs you are expecting from your decision table similar as you would do with uh sub flows and flow actions yeah thank you so much Lisa and as you said you know we have the inputs which are very similar to subflows and then in decision world the result columns which we'll take a look at are the equivalents of the outputs they Define the types of data that you'll return once the rules are executed so there's a few different ways to approach input creation um especially when you're pulling data from existing metadata and service now so in this case all of the data we want to use to make our decisions lives on the application record I'm actually going to create a few different inputs to illustrate to you the flexibility of the tool and the different ways you can approach creating your decision table based on your use case the first thing we're going to do as I just mentioned is create an input for that application we're going to label it application and the data type is going to be a reference because we will take in a record from that class application table you can see here that you can apply filters to reference inputs I'll talk more about that when we build another input and show you how it works we're going to Define this as a mandatory input and what that means is that when you call this decision table in a flow by using to make a decision action it will list out what your input variables are and if this toggle's turned on it will require you to provide data for each of the inputs that have mandatory turned on so this is what we want in this case because we want data for all of our inputs from here I'm going to create a couple more inputs if we go back to our Excel spreadsheet of requirements we have the Min age and the max age I'm going to pull that data directly from the application we also want to look at the class and whether the course has a prerequisite so I'm going to approach these with different inputs though as I mentioned and as I'll show later we could do all of this just using that application input so next let's add an input for class this is also going to be a reference because we have a table that stores our classes and we can actually from here apply a reference filter so that when we're clicking into the drop- down menus and choosing the specific classes we want to apply for our conditions we can see a more narrow list based on what we're trying to do with this decision table so in this case I'm going to apply a filter based on the semester so this decision table is only going to be used for our summer 2024 semester so I only care about classes that are associated to that semester lastly we're going to add one last input for whether the course requires a prerequisite this is a choice field on our application record but if you want to create a choice input you have some flexibility and I want to show that off here we're going to choose a choice list here you can either create a new Choice list so create a custom Choice list you can see that you can add Choice One you have the label and the value and start building your own choice list this is really powerful because then when you're building your decision table rather than typing string values and risking errors you're asking users to just choose from specific values the other thing you can do is reference existing Choice lists on a table so that you don't need to rebuild a choice list that already exists let's switch to that option as you can see here we can choose the table that the field sits on and one thing you'll notice is that this feature of referencing an existing Choice list allows you to choose tables that are in the same scope as your decision table so we built this decision table in the examples scope the class application and the classes tables are also a part of that scope I'm going to choose the class application table and then I can see any choice fields that live on that table in this case I want to pull the choices from the taken prerequisite field um and I'll just change the name of this to make it even clearer now that we have our inputs and we've defined what data we need to make decisions I'm actually going to jump down to the output section which is covered under results this is going to Define what data we're going to return once you evaluate your rules in the decision table in this case we want a couple of different types of information we first want to know whether the applicant is eligible for the program and then we want to know if they're eligible what group should their application be assigned to we'll do this by adding result columns the first is eligibility and ibility is going to be a true false value as you can see under result types we support all of the same field types for results that we do for our inputs and we support all top used service now field types in our inputs and results so let's add a true false result type here again you're able to add a description to provide context if you're going to be handing this decision table to anyone else who may need to understand why you made the decisions you made when you were buing it and then again we'll add a second result column in this case it will be for assignment group this will be a reference because we're going to use the group table and then as you can see we can apply reference filters here as well to make it even easier to fill out your result values when you're building decisions let's add a reference filter so that we only look at the departmental groups because those are the only groups that we're going to assign applications to we can add a filter based on the typee field and we can say that this type contains departmental groups all right well now that we have our input variables and our output variables in place let's go ahead and Define how we're going to use our input data to make decisions the inputs Define what is available for us what's at our fingertips what can we use to build conditions and then the condition columns here are are used to narrow things in to say if this is everything we can use what do we actually want to use information wise to make our decisions in our case we want to use the application input to pull that agit Program start information we're going to add a condition column from here and this condition column will be for age of program start again you can add a description the input is automatically linked to that input you created this condition column from and then down here we decide what data from this input do we want to evaluate do we want to just pass through the whole record and use a drop down of Records to choose our when we're building conditions in this case we actually want to use a field on this table so we can choose the field option and we can select agent program start as the field we want to use when we're building these conditions you can then see the condition type and you can choose the default operator and if you know you're regularly going to be using a specific operator you can choose that as a default to pre prevent having to click and change menus in this case we'll leave it as is taking that action has added a column to our decision table below we're going to add a couple more columns here we're going to take a look at this class input and we're going to actually add a direct column in the table for class because if you remember going back to our Excel file we need to look at this class in this case we actually will evaluate the reference record directly rather than a field on that class table lastly We'll add a condition column for whether the um applicant has taken the prerequisite and that's going to be a choice whenever you have inputs that are not a reference it's a little bit more straightforward because there's a onetoone relationship between that input and the column in the decision table here we can just take a look make sure everything looks good and then add the column I'm going to save our work because we have done a lot here what we built here is really powerful because what this lets us do now that we have this structure is quickly and easily add the meat of our decision table which is the actual rules what different combinations of conditions produce what combinations of results so let's start doing that we'll show you a few different ways that we can add rules to our decision table and easily translate our logic into something that can be used in our flows and in our scripts across the platform so first I'm going to add some conditions for the teen classes in these cases the age of program start is between 14 and 19 our between function is inclusive so 14 and 19 are included in that range the class is tie-dye for teens and it doesn't matter whether someone's taken the prerequisite because there is no prerequisite if someone meets these criteria they're between 14 and 19 in age treat the space between the columns is an and and the class they applied for is tiedye for teens and we don't care if they've taken the prerequisite then we can Define here that they are eligible and we can set the assignment group to the teen Arts board we now want to add another row for our watercolors class we have a watercolors for teens class and in this case rather than starting from scratch we can actually leverage the duplicate row feature in decision Builder and in this case instead of adding a new FR from scratch we can actually utilize the duplicate row feature in decision tables if we scroll down to this menu over our decision row you can see the duplicate icon here when you click it it will automatically add a new row below with all of the same values in it in this case the only thing we want to change is that the class is watercolor let's keep adding rows and rules to our decision table so now that we've duplicated this one we have watercolor fores I'm also going to add a new row for our other tie-dye class you can do that by adding using the plus signs above and below the rows we also have in this overflow menu the ability to add explicitly here or you can add a new decision Row from the bottom of the table I'm going to use the plus sign to add a new row to our decision table in this case the age of program start is going to be greater than 15 the class is going to be tie-dye and there's no prerequisite so whether they check the prerequisite or not is not applicable here this will make someone eligible and they would be assigned to the textiles assignment group looking at this I've realized that I've missed an important condition that I wanted to add to my decision table at our school the minimum age for any program is 14 so what I want to do is just add a condition that excludes and makes ineligible anyone who applies who's less than 14 I'm going to add a new row to do that here anyone whose age of program start is less than 14 is not eligible you can see here that I've left class and whether they've taken the prerequisite blank what that does is just remove them from the evaluation criteria so when the decision table runs through this condition it will just say if their age of the program start is less than 14 then they're not eligible it will exclude these from that condition this should actually be my first condition in the decision table because I want to filter out those applicants and get them out of the evaluation before I even start looking at the other conditions decision tables execute sequentially so when you go through the rules it's going to look at rank one before it looks at rank two before it looks at rank three Etc so what you can do is structure and order your rules in a way where you have any exclusion criteria at the start to make sure that you're optimizing your performance and getting those conditions those scenarios completed quickly um and then you can go through and look at the different categorizations where you actually do expect to return results I'm going to move this row to the top of the decision table using this drag and drop function the other way you can reorder rows is in Excel which we'll take a look at and again pointing to that Safe Harbor statement coming in the future you'll be able to reorder rows in your decision table by typing a new number into that rank field I'm very excited for that part that sounds very handy especially for larger decision tables you know the drag and drop is we all know that pattern it works really well but it is a lot more difficult when you have a hundred rows in your decision table and you want to reorder them yeah how do you when do you scroll do you just move to the top does it scroll for you it's much easier to just enter number so I'm going to save the work that we've done and what we'll take a look at here you know I could keep building in decision in in the decision table excuse me but instead I want to make this faster I'm just going to do this in Excel so I can export our decision table and the work we've done so far into Excel all right and then what I'm actually going to do is just copy and paste some data in here to save us all some time what I'll show you is that our Excel import feature has some powerful air handling in it and I want to give you a demo of how that works so here we've chosen excuse me tie-dye for teens already this is a picture of our decision table with some errors in it here I've typed out 15 instead of having the integer I've deleted some of the operators and I chose invalid Choice values let's see what happens when I try to import this back into the decision table oops this is what I'd like to see I mean not what I'd like to see if I don't think I have errors but knowing that I do this is good so you'll see here we actually not only point out where you have errors but we'll give back information about what those errors are so you can easily resolve them so I will change this to the number 15 this error is that the operator can't be empty so I can go back down here and add an operator and then lastly I can change these to be valid Choice values and Advanced Metal working um in this case if they don't have the prerequisite they are not eligible and if they do have the prerequisite they are eligible so I'm going to save those changes come back to the decision table and I can import that error file with corrections directly back into our decision table that is super useful you don't have to go back and forth and try to fix those in the original export but you can just take the error file exactly awesome we were trying to let you stay in one place because I think it's so confusing to do that switching so this export was successful you can see here that we're going to add a number of new rows to the decision table all of our logic has been translated over here we have a lot more um a lot more conditions and we've actually captured everything that was in this requirements dock with our decisions the other thing to note is that we have a default eligibility which is false which is basically there as a catchall in case we have an application that comes in and maybe we forgot to add a class here it's just not going to tell anyone that they're eligible by accident um this is especially helpful when you're using decision tables um for records with assignment groups you might miss some Niche criteria so you can use like a catchall assignment group to say if it's not in any of these specific groups maybe assign it to General support for example or general fulfillment all right well we have made a lot of progress before we jump into some of the peripheral functions of the product I just want to show you one more thing on the Excel experience this history button will show you your Excel Import and Export history so if you've use it if you've been using export to excel import from Excel I know that it can get confusing we have naming conventions that include the name of the decision table and the time stamps of imports and exports and whether it's a success file or an error file but you can always come back here to your history to download those files and actually see that um back and forth history particularly valuable if you are doing a back and forth with someone on the business side who maybe isn't logging into uh workflow Studio to manage the decision table directly all right so now that we have our draft decision table in really solid state I think let's do some testing so we can take a look I've created some test data let's look at a list here this application is for Megan Burke she applied for the metal working class um and her age at Program start is going to be 18 and she doesn't need to take a prerequisite and the expected outcome of this will be that she's eligible because she's at the right age um for the class and she doesn't need a prerequisite let's actually see if that's the case when we test this in our decision table the test feature is appears up at the top and you can test anytime you've saved your changes you can choose whether you want to test your draft version or your publish version in this case we only have a draft so that's what's available to us as Lisa shared earlier you can run your decision table two ways either returning the first decision that matches or returning a list of decisions that match in this case given the way the decision table set up we really only care about the first matching result so we're going to stick with this method the application is going to be megans and then this will seem a bit redundant but we're going to capture the data that lives on this application so the class that she's applying for is the metal working and it's not applicable if she's taking a prerequisite we can run this test and see that she is eligible for the class and the assignment group is the metal and glass Department that's exactly what we were hoping to see so that's great news success amazing now that we feel good about our decision table we could run more tests but for the sake of your time I'm going to keep us rolling we can go ahead and publish it this will make it available to use in a flow or in a script when we go to publish our decision table we get some confirmation information to make sure that we understand what we're actually doing the reason for this is that we only keep two versions of your decision table at a maximum right now the draft that you're working on and whatever is published and out in the wild so if you're creating a new draft to make changes then if you want to publish that draft you're going to override the existing published version of the decision table with the new information we just want to make sure you're aware when we publish the decision table it immediately becomes readon you can see the input section collapse but collapses but is read only and you can see all of your rules but you can't change them you can report them to excel if you want to share them for informational purposes publishing the decision table also made it available for us to call from a flow or from the apis if I realize that I want to make some changes to my decision table I can still make those changes I just do it by creating a new draft so I come up here and create click the create draft button what I realized is that I want to add a little bit of a different condition for one of my classes you can toggle here between your draft decision table and your published decision table if you want to take a look at what's going on with each in this case I have a bit of a weird Edge case scenario for oil painting 101 I actually want the agit Program start to be greater than 15 for new students but I want it to be greater than 14 for students who have already taken a class because this class is sometimes a great entry point to our programming in this scenario where you want to be doing complex condition that don't really follow the conventions of a decision table you do have the ability to do that you can do it by going to this overflow menu and clicking into decision rule view this is the view to use if you have requirements around using or conditions um or accessing data that's available on that reference record that you don't have a corresponding column for I would recommend using this feature sparingly and only when you have absolutely essential scenarios where you need to add an edge case that doesn't follow the conventions of a decision table because you do lose some of the power and um Simplicity of being able to read and work with things in that table structure but I'll show you just so you know what it is and how to use it here we have this condition set for um agent program start I'm just going to make some changes here I'm going to say if it's greater than 15 and the classes oil painting 101 and the student is a returning student or is not a returning student and then we can do a new condition set that says their age is greater than 14 and the class is oil painting 101 whether they are returning student is true I click done and that takes me back into the decision table as you can see we let you have these conditions you can see a preview of them and open them in that view but you because you're using data that is using or conditions the decision table uses and conditions and you're pulling data that's not present in these columns um you will just see your condition merged across all of the condition rows now that we've made this change we can publish because we do want to use this as our new active version of the decision table and we can take a look at a couple other features before we finish up our demo now that we have our published decision table we can go back and use it in a flow which I'll show you in a moment but there's a couple other things we can do the first is we can create a code snippet for the decision table so if you wanted to use your decision table in a script rather than directly in a flow we can use this code snippet feature um Lisa showed this off when she was talking through the features it has come out with our Washington release and makes it much easier to use your decision tables wherever you're scripting on the platform you can see here that we have the two different execution methods of the decision table and you could just copy this code into a script and link up the inputs and then start using the outputs you can learn more about our documentation here and you can also copy this code the other things you can do from this overflow menu are duplicating the decision table which lets you copy over all of the content that we've been working on as I mentioned this decision table is for our summer 2024 session we might want to use a different decision table for our fall session so I could actually copy over some of this data and then make tweaks to it for fall rather than starting from scratch um you can rename your decision table you can choose if you want to duplicate your publish version or your draft version in this case we only have a published version so that's what we'll copy you can also copy it into a different scope if you want to use delegated development for a new version of this decision table lastly you can choose whether you want to copy over for your rows or whether you only want those kind of column headers and inputs depending on what the different use case is in our scenario we might want to copy over the rows because we just want to make tweaks we don't want to start again from scratch and there might be some similar classes so I call this fall when I click duplicate what it will do is open this up in a new tab in workflow Studio you'll be able to see that you have this decision table in a draft format so you can just start working on it and making changes the last thing I'll show you before we get back into our flow is what it looks like um when we're already using a decision table in certain flows so this is an example of the decision table we've been building that I've already integrated into a flow in this overflow menu you can choose to see related objects and in here you can see that this decision table is used by the demo art class applications flow and from this menu we could click into it and open it in a new tab in workflow Studio here you'll also see subflows where the decision table is being used um and if you are working in the decision table but don't have access to where it's being used in a flow or subflow you'll at least get the indication that there's something there that you can't see and you can work with an administrator to get access or to have them take a look all right well we've done a lot of work let's reap the benefits of it in our flow I'm going to go back to this art class applications flow it triggers when the class application's created and as we decided and I'm going to work in diagramming View I really prefer that rather than adding a bunch of if statements we're going to add a node to call our decision table decision tables live under flow logic and you can choose make a decision here here we want to decide eligibility and assignment group and we're going to use the published decision table that we just created what you can see is that a few things happen when we choose the decision table it will default the execution to first decision that matches which is exactly what we want it will also automatically add branches to our flow based on the results of that decision table in this case we don't want to Branch our flow in different directions based on the result we just want to change the values that we're setting on some of the fields so we're going to remove those branches you can then see the three different inputs that we created and you can see that they're all mandatory here because we made them mandatory in the decision table we'll map in data to each of these inputs and then when the flow EX executes each of those data pills will actually Hydrate with real data that our decision table will evaluate the application is coming from the trigger then our class is going to come from that application record and lastly whether they've taken the prerequisite will also come from the application record so that's how simple it is to add your decision table to your flow and Link it up to all of the data that's going to be passed to the decision table when the flow executes the other thing we can do with this is now use use the results of the decision table to do more things in our flow what we wanted to do was branch in two directions one way if they're eligible for the programs one if they're not so here because I want to Branch only on a specific result I'm actually going to use an if statement connected to the decision table to do that branching for me here I'll say if eligible and then for the condition you can come down to this make a decision action and click through a couple nested layers to get to your result columns here eligibility true false if they are eligible then we want to follow One path and then if they're not we're going to follow a different path the last thing we'll do in this flow is use the assignment group that we have in a result column from our decision table so if they're eligible we now we want to set the assignment group on their application so that we know what team needs to overse this application review process we'll use the update record action the record we want to update is their application and we want to update the assignment group and dynamically set that assignment group based on the result of our decision table so as you can see this flow now with only four different steps in it is ma manages to encapsulate all of the logic that lives in this spreadsheet plus the assignment group logic by moving that logic into the decision table that we built okay well now we have created a decision table we've added all the rules to manage our logic we've integrated that decision table back into a flow what more could you want I'm going to show you one more thing and then we will end our demo for today and hopefully you will go off and build many decision tables to make your flows and code much more maintainable the last thing I'm going to show you is just what it looks like if you were to build that decision table with a single input instead of multiple inputs so if uh if we go back to original decision table I'll actually remind you that we have an input for application one for class and one for the prerequisite Choice value each of those have corresponding condition columns we have a bit of color coding here to show you what they're linked to and they're all linked to different inputs if we wanted in this scenario we could just have a single input for the program application and then we could have individual condition columns for each of the fields on that program application so if we look at this condition column here it's just using a field as data to evaluate from that application record it's pulling the class field and on here this is pulling that field for whether someone's taken the prerequisite whenever you want to use a field especially a choice field um and you want to have those existing Choice values if the choice field lives outside of the application scope that you're working in you can still access the choice value by creating a reference input and then adding a column for that choice field so that is really the best practice I think wherever possible if you're using data that's hooked into the service now schema your cleanest approach for building your decision tables is to create a reference input to the table where it lives and then build different condition columns based on the fields from that reference there's also different use cases where creating individual inputs makes a lot more sense if you're creating decision tables for service catalog use cas cases where you want to have different questions from your catalog items evaluated in a decision table you will have to go ahead and create individual inputs for each of those questions so we give you the flexibility to do both and I hope after this demo you feel well equipped to go ahead and build your own decision tables in however best suits your use cases so thank you so much for your patience and for sticking along for the ride thank you Lisa for all of the context and and for providing this platform thank you so much Julia for this this awesome demo to wrap up our session my main takeaway for you is this everyone can build decision tables to decouple logic from code anywhere on the now platform create reusable decision tables to remove complexity from flows and script this results in less effort necessary for your application life cycle and reduce the change burden if you like this session please upload this video and whether you liked it or not this survey is your chance to provide feedback or comments about this Academy I'm looking forward to reading your feedback you can find the link in the video description or use the QR code shown on the screen if you're interested in other topics Beyond workflows let me recommend my colleagues Academy series each of them covers a different part of the now platform we have content about conversational interfaces including virtual Agent mobile apps analytics next experience workflow core platform and of course artificial intelligence while on the topic of more content if you prefer to read up on topics at your own pace check out the workflow automation Center of Excellence on the community I've collected resources and links and I'm regularly publishing new articles with best practices FAQ and guidance around flows playbooks and decision tables thank you for choosing to spend some time today to learn about workflow automation on the now platform thank you for providing your feedback and questions to help us make these sessions better for you until next next time bye